Compile Error in DLL

[jezwarner]

I am creating a dll with a public class, that I want to accept a textbox object as a byref parameter in a public procedure. This produces a compile error stating that I cannot use private module objects as parameters or return types in public module procedures. This is the type of error I would expect if the parameter was a class object that had its instancing set to private. Can anyone explain why this is occurring here, and hopefully with a solution?

[simonm]

You can pass control references to DLL's but you will probably have to declare it as a Control rather than it's specific control name.

As for why you can't, I'm not too sure.

[crispin]

Yeah, I had problems with this sort of thing a while back, I had to bite the bullet and endure late binding in this case and used code like this:

Public Function Tester(tB As Object) As Long
If TypeOf tB Is TextBox Then
    Debug.Print tB.Text
    'Do other bits here
    Tester = 0
    Exit Function
Else
    Debug.Print "NOT A TEXTBOX"
    Tester = -1
    Exit Function
End If
End Function

I know its not great, but I didn't have the time to mess around.

[crispin]

Heres a slimy way of getting round it:

Pass an object pointer (to the textbox) to a public function, then resolve the pointer, and do whatever you want - mail me : [email protected], and i'll send you a sample project.

[jezwarner]

Cheers for help guys.

I've sorted it by passing in the textbox as an object, and then setting a privately declared textbox to the object which gets passed in. This works ok as long as the object is validated as a textbox first.

I still don't understand why it has to be done in this manner - I'm sure there's a VERY good reason (hmmm).

[samwise]

I had this exact problem when I was developing a VB app. In it, I passed a combo box to an ActiveX dll, to load it with information.
The program would not compile, for the reason you stated above.

Fortunately, I was working at Microsoft at the time, in the Visual Studio department, so I asked them about this.

They said it had to do with passing a private class into another thread. (or something like that).

To get around this, I passed the combo box as an object, and was able to make it work.

If you create a module, in the same project, then you can pass a text box into a subroutine in the module.

However, if the module is located in a different ActiveX dll/exe, then there is a threading problem. A dll is supposed to run in the same thread as the module it works with, but it is supposed to create very unstable code, that could cause problems. If you were working with an ActiveX exe, then you would get even more problems, because it runs in its own thread.

If you do this, could you use a Mutex to make sure the program doesn't crash?

Samwise Galenorn
[email protected]