GetObject and VB6 ActiveX exe

Question

The VB6 help on GetObject says "You can't use GetObject to obtain a reference to a class created with Visual Basic" (the very last sentence!). My VB6 GUI exposes objects as an ActiveX exe, for other components to manipulate. I want the other components to connect to the GUI that's already running, rather than start a new instance of the exe. I've found using GetObject does work, if you use this syntax:

Set myobj = GetObject("", "ProjectName.ClassName")

It worries me that the help says this shouldn't work, although I have done quite a bit of testing and haven't found any problems so far. Any COM experts out there who can tell me whether I going to run into problems down the line? And would I be OK with CreateObject anyway?

The ActiveX exe settings are: thread pool with only one thread. The class has MultiUse instancing. It's possible these settings are enough to prevent CreateObject starting a new instance of the exe anyway. Is that correct?

Answer 1

The documentation is confusing, but correct. The MSDN page you reference helps to explain why your GetObject call doesn't throw an error:

If pathname [the first argument] is a zero-length string (""), GetObject returns a new object instance of the specified type. If the pathname argument is omitted, GetObject returns a currently active object of the specified type. If no object of the specified type exists, an error occurs.

It's subtle, but the implication is that

GetObject "", "ProjectName.ClassName

is actually equivalent to

CreateObject "ProjectName.ClassName"

That is to say, passing an empty string to the first parameter of GetObject makes it operate exactly like CreateObject, which means it will create a new instance of the class, rather than returning a reference to an already-running instance.

Going back to the MSDN excerpt, it mentions that omitting the first argument to GetObject altogether will cause GetObject to return a reference to an already-running instance, if one exists. Such a call would look like this:

GetObject , "ProjectName.ClassName" 'Note nothing at all is passed for the first argument'

However, if you try to do this, you will immediately get a run-time error. This is the use-case that the documentation is referring to when it says that GetObject doesn't work with classes created with VB6.

The reason this doesn't work is due to how GetObject performs its magic. When the first parameter is omitted, it tries to return an existing object instance by consulting the Running Object Table (ROT), a machine-wide lookup table that contains running COM objects. The problem is that objects have to be explicitly registered in the Running Object Table by the process that creates them in order to be accessible to other processes - the VB6 runtime doesn't register ActiveX EXE classes in the ROT, so GetObject has no way to retrieve a reference to an already-running instance.

Answer 2

I want the other components to connect to the GUI that's already running, rather than start a new instance of the exe.

The trick is to remember that in a ActiveX EXE it can be setup so that there is only one instance of the LIBRARY running. It is correct that you can't reach and just pluck a given instance of a class across process boundary. However the ActiveX EXE can be setup so that the GLOBAL variables are accessible by ANY instance of classes.

How to exactly to do this gets a little complex. You can use a ActiveX EXE as a normal EXE the main difference is that you HAVE to use Sub Main. You can also check to see if it run standalone or not. Now I am assuming this is the case with MarkJ's application.

If this is the case what you need to is create a application class and set it up so that that when it is created (by using Class_Initialize) that it is populated with the current running instances of forms and collections.

I strongly recommend that you create an ActiveX DLL (not EXE) that has nothing but classes to implemented as interfaces. Instead going of going

'Class ThisGUIApp
Public MainForm as Form

You create an interface that has all the properties and methods needed to access the elements of the mainform. Then you go

'Class ThisGUIApp
Public MainForm as IMainForm

Private Sub Class_Initialize
  Set MainForm = frmMyMainForm
End Sub

'Form frmMyMainForm
Implements IMainForm

You do this because while you can send a Form across application process things get wonky when you try to access it members and controls. If you assigned via an interface then the connection is a lot more solid. Plus it better documents the type of things you are trying to do.