Problem Passing Form Control to an ActiveX DLL.
Hi, I'm quite new to this forum, it's my first post. I have a big problem, some VB6 code I have the chance to maintain doesn't work anymore.
I didn't change any code, but accidentally removed one of its dependencies (APEX True DBList Pro 6.0) and then reinstalled it after realizing my error. But now the project crash with "Run-time error '13': Type mismatch", so I investigated this problem and didn't found any way around it.
What is causing this error is that our main 'Standard EXE' application is calling a function (SetStdForm) in an ActiveX DLL with one of its Form has argument. Here's the isolated code that call the DLL:
Public WithEvents Rules As PCRules.Rules
Private Sub Form_Load()
Set Rules = New Rules
Rules.SetStdForm Me
End Sub
In that DLL, the Form is received by SetStdForm as an Object and then it set a private variable of type Form with this Object. It's during the Set that the error happen. Here's the code form the DLL:
Private p_Form As Form
Public Function SetStdForm(ThisForm As Object, ...)
...
Set p_Form = ThisForm
...
So my questions are: Why is this error happening, it was working before and is still in production? What's the relation between this error and the dependency I reinstalled, considering I reinstalled the same version at the same place in the filesystem?
The DLL act as a kind of stylesheet, it apply some custom properties for every control in the main application. It's quite encrusted into the main program and I can't remove it easily.
In my searches to find a way around that problem, I've found this Knowledge Base article which is relatively close to it: http://support.microsoft.com/kb/190210.
Thank you for reading this far!
[1907 byte] By [
budu] at [2007-11-20 11:36:59]

# 2 Re: Problem Passing Form Control to an ActiveX DLL.
First, I want to thanks again all people who replied.
Ok, now I've partially fixed my problem, but there's a lot of question remaining plus some new ones. I've removed all references from the main application to the Rules DLL to be sure it was not the cause of the problem and it's working flawlessly. But this DLL was injecting a lot of really strange keyboard shortcuts to all forms and our users are extremely used to them so removing them is out of the question.
So I set out to test the Rules DLL independently by adding to it an other empty Standard EXE project. The example code calling SetStdForm is working now that the form is in the same project group as the called function. This is quite strange, because it never was in a group before.
After setting the form the Rules DLL do the same thing with each controls on it, which works too. But then, another Type Mismatch happen, in a really strange statement, here's some code:
Private p_Control As control
...
Public Function SetStdControl(ThisControl As Object, ...)
...
Set p_ComboBoxRules = New ComboBoxRules
p_ComboBoxRules.SetStdComboBox p_Control
Set p_Control = p_ComboBoxRules
From what I assume (because I'm really new to this language), VB doesn't any other means than the Implements keywords for inheritance, thus ComboBoxRules doesn't inherit from anything. So there's no polymorphism possible for the last operation and it will necessarily result in a Type Mismatch error. How can this be?
budu at 2007-11-9 19:33:50 >

# 3 Re: Problem Passing Form Control to an ActiveX DLL.
Seems like you reversed two statements, but it may have been set properly before... Not sure. Try this:
Change THIS:
p_ComboBoxRules.SetStdComboBox p_Control
Set p_Control = p_ComboBoxRules
to THIS:
Set p_Control = p_ComboBoxRules
p_ComboBoxRules.SetStdComboBox p_Control
which makes more sense to me
# 4 Re: Problem Passing Form Control to an ActiveX DLL.
to dglienna:
The p_Control variable already set correctly before. Thanks anyway.
Really strange things happen here, I found how to fix the bug I had in my last update. The Set statement was totally wrong, it should have been:
Set p_Control = p_ComboBoxRules.stdComboBox
Which make much more sense, but the wrong code is the only source code we have for this DLL and it is in production. It should not work, but it do.
Thanks to all who replied, I'll considered this problem solved, even if I don't really have a good understanding of what happened.
budu at 2007-11-9 19:35:54 >
