Hi

The VB6 help on GetObject says "You can't use GetObject to obtain a
reference to a class created with Visual Basic." 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 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?

Thanks
mark

<mark.tunnard.jack***@googlemail.com> schrieb im Newsbeitrag
Then the help is obviously wrong (but don't know the context
in which that was stated).
Maybe they meant - you cannot use GetObject against
Private Classes in a given Project - and it also will not
work against Public Classes which are hosted in an
AX-Dll (these require CoCreateInstance or CreateObject).

GetObject always expects an already *running* instance
of a COM-Class, hosted in a Process, which is capable
regarding (cross-process) OLE-Marshaling.

And a VB-ActiveX-Exe is such a "marshaling-capable"
hosting instance (process).
Another such instance (more a sheduler) is for example the
Running-Objects-Table. The ROT, which is visible
system-wide and could also offer classes for OLE-
marshaled access, reachable per GetObject then,
when you register a "normal Public Class" (which could
also be defined in an AX-Dll) from a running Std-
VB-Exe-Process.

That should work fine, as long as your hosting-process
which offers these Object-interfaces for marshaling, always
"is there" for the other (satellite-)processes - be it in
case of "connecting" (per GetObject) - or in case of
"accessing and using the marshaled methods" from a
client-processes point of view as long as the client
(and the marshaled clientside object-ref) lives.
In case of a clientside connect-call you will get a nice
Error-message (in case your AX-Exe-Server is not
yet running) - more problematic to handle is the case,
should the Server-Process go out of scope, in case
the client-processes already got a marshaled ObjPtr
to work against (the clientside Object- or Class-Variable).

Method-Calls on such an Object-Variable (which are
marshaled under the hood) always need special attention
and error-handling in your client-apps.

But that's a common problem, which is there in each
cross-process COM-access scenario - it has nothing
to do with GetObject (which is only the connect-call).
After a successful GetObject you got your marshaled
(remote-) COM-ObjectVariable at hand in your App -
you can then forget about GetObject - what now
applies, are the rules, how to work with "COM-Remote-
Objects" (as for example is exactly the same as when
you work against a "remote-sheet" of an Excel-Instance).

Olaf

Thanks Olaf.

Here's a link to the VB6 help on GetObject. The sentence I quoted is
the very last one, there's no context at all that I can see.

http://msdn.microsoft.com/en-us/library/aa445016%28VS.60%29.aspx

mark.tunnard.jack***@googlemail.com's wild thoughts were
released on Wed, 27 May 2009 05:00:24 -0700 (PDT) bearing
the following fruit:

Well, it would seem to be wrong.

fJan Hyde <StellaDrin***@REMOVE.ME.uboot.com>'s wild
thoughts were released on Wed, 27 May 2009 13:15:38 +0100
bearing the following fruit:

Actually, that help file is for VBA. And when talking about
'vb' in the context of VBA then it's probably correct since
any classes would be part of the macros and not an activeX
component.

<mark.tunnard.jack***@googlemail.com> wrote in message
That last line doesn't appear in MSDN Help (Oct 1999).

I suspect it was added later as a misguided attempt to remove some confusion
over the misnamed "class" argument. This argument is actually a string
identifier for an APPID (ProgID).

While any "class" can be uniquely referenced by some combination of
<appname.objecttype>, <appname.class>, <library.class>, <project.class>,
<etc>, only published automation objects have AppIds. That's why the type of
classes Olaf mentioned would be excluded as valid "class" arguments.
Referring to these excluded classes as "a class created with Visual Basic"
is, to put it mildly, less than helpful and only adds to the confusion.

-ralph

  Another point that might be worth exploring:
According to the MSDN page your method will create
a new instance. Dino Esposito says the same thing
in his VBScript book. (I'm assuming the function
works the same way in VBS as in VB, but I'm not
certain.)
  He says that this always returns a new object:

GetObject("", "Server.Class")

while this will return a running instance, or an error
if there is no running instance:

GetObject(, "Server.Class")

  Further, he says that which instance you get is
undefined but that in his own tests he always
got the oldest instance.


  On the original issue, I don't know for sure, but
I'm guessing they meant that you can't reference
a class internally. If the statement is taken literally
then it implies that there are different kinds of
publicly creatable COM objects.

My hunch is that their intended meaning would have been more clear had they
said something like "You can't use GetObject to obtain a reference to a
Class Module previously instantiated within the same Visual Basic project".

That's part of what ActiveX EXE's and GetObject() are supposed to do...

Note that they mentioned CreateObject in the same paragraph. You are
brushing up against multithreading.

Visual Basic Concepts
Scalability And Multithreading
http://msdn.microsoft.com/en-us/library/aa716297(VS.60).aspx

<mark.tunnard.jack***@googlemail.com> wrote in message
In some areas in MSDN October 2001, I see them using that phrase, and in
others clarifying that the restriction is for classes created with VB4 or
earlier. MSDN Online version shows the same typos.

Here is where the correct statement appear(In both MSDN October 2001, and
the online version):

Windows Script Host, GetObject Method
http://msdn.microsoft.com/en-us/library/8ywk619w(VS.85).aspx

Quote: "You cannot use the GetObject method to obtain a reference to a
Microsoft Visual Basic class created with Visual Basic 4.0 or earlier."

Show quote Hide quote I doubt this statement is any more "correct" than the newer one. It provides
even more confusion since there were no non-GUI classes earlier than
VB4-32bit.

[Perhaps, the author meant to point out that GetObject only worked with
ActiveX Automation (OLE2) and not earlier DDE or OLE1 automation schemes???]

One might provide several guesses for why this statement was added and
subsequently modified. However, no matter what specific case the author may
have had in mind, the statement itself is remarkably unenlightening for any
of them. :-)

-ralph

Help with a bit of maths
Create Icon File From Resource
Anyone know of a good Help Authorizing Tool
Prohibit Paste
Changing a property on a control
Vista and AutoRedraw
Phone system integrated in vb app
Sort UDT vs Database
How do I stop opportunistic record locking from causing massive de
General Question on Deployment Stratagies