COMInterfaceImp subclass registery LocalServer32 problem

Hi!

We're doing a bit of research on Dolphin to see if it is a good
development environment for implementing an OPC COM framework. So far,
in my limited experience, I like its tool set & wizards.

However, I've got a wee bit of a problem in trying to connect to the COM
implmentation object. Whenever I do a ... createObject: 'foo.bar', COM
starts up the Dolphin server, but the server times out without a valid
connection being established.

I got to looking in the LocalServer32 registry entry that's created when
doing COMInterfaceImp subclass | register. I have two installations of
4.0 trial (I'm hoping to buy one soon -upgrade my 3.0 license-, if these
tests pan out) One in c:\Program Files\Dolphin 4.0 & one in
c:\winnt\profiles\....). The funny thing is that even though the image
I'm running is out of c:\winnt\...., the LocalServer32 registry entry is
"c:\Program Files....".

Questions:

* The register method is pretty simple but I don't understand where the
...ExternalLibrary moduleFileName: nil.. gets the server path string? Do
I have a messed up installation perhaps?

* Is the proper Dolphin protocol to start a particular image (not just
the last opened image) in a COM object registry to pass a path to a
particular .img file? It seems this is a better way to do it rather than
  relying on the default image. (btw-I tried to do this, but it puked
w/o even trying to start that specified image)

Side question..
* I didn't see anything specific in the o-a web site about how licenses
for the Professional suite is handled. On a machine, developer or site
basis? Say we have 3 developers wanting to work on with Dolphin? Do we
need 3 licenses?

* Further aside, am I safe to assume that if I want to use a license for
my own development at home (mostly to further my work development) then
I would need a seperate license? As opposed to reusing a work license?

thx much,

Eric

I should add the error dump, but I'm not sure how helpful it will be.

thx again,

Eric

3:30:28 PM, Monday, October 22, 2001: Unhandled exception - a
HRESULTError('HRESULT Error: Server execution failed (FACILITY_WINDOWS)')

OLELibrary(ExternalLibrary)>>invalidCall
OLELibrary>>coGetClassObject:dwClsContext:pServerInfo:riid:ppv:
OPCDAIOPCServer class(COMInterface
class)>>onCLSID:outerIUnknown:hostName:licenseKey:
OPCDAIOPCServer class(COMInterface class)>>onCLSID:outerIUnknown:
OPCDAIOPCServer class(COMInterface class)>>onCLSID:
OPCDAIOPCServer class(COMInterface class)>>createObject:
UndefinedObject>>{unbound}doIt
CompiledExpression>>value:
SmalltalkWorkspace>>evaluateRange:ifFail:debug:
SmalltalkWorkspace>>evaluateItIfFail:debug:
SmalltalkWorkspace>>evaluateItIfFail:
SmalltalkWorkspace>>inspectIt
Symbol>>forwardTo:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
SmalltalkWorkspaceDocument(Shell)>>performCommand:
CommandQuery>>perform
DelegatingCommandPolicy(CommandPolicy)>>route:

Eric Winger wrote:

Eric,

> We're doing a bit of research on Dolphin to see if it is a good
> development environment for implementing an OPC COM framework. So far,
> in my limited experience, I like its tool set & wizards.
>
> However, I've got a wee bit of a problem in trying to connect to the COM
> implmentation object. Whenever I do a ... createObject: 'foo.bar', COM
> starts up the Dolphin server, but the server times out without a valid
> connection being established.

I've never tried to register and auto-start a development image; instead, I
have development images register servers when appropriate.  My deployed apps
gets registered via a .reg file as appropriate.  In truth, I haven't had to
touch the COM specific stuff in a very long time (in computer years anyway).


> I got to looking in the LocalServer32 registry entry that's created when
> doing COMInterfaceImp subclass | register. I have two installations of
> 4.0 trial (I'm hoping to buy one soon -upgrade my 3.0 license-, if these
> tests pan out) One in c:\Program Files\Dolphin 4.0 & one in
> c:\winnt\profiles\....). The funny thing is that even though the image
> I'm running is out of c:\winnt\...., the LocalServer32 registry entry is
> "c:\Program Files....".

That could be glitch in the registration code.  IIRC, the sequence was that
I got everything working with .reg files etc., then OA added more
sophisticated support, but, I never adapted to it because I found DCOM to be
unusable and as a result would have little to gain by a slicker way to
register apps with COM.  As it is, I have a few key things that already have
working installers built "the hard way" but the work is done.

If the registered .exe path looks wrong, you might try editing it (with
great care of course!) using regedit.  Rogerson's "Inside COM" is a great
source of info about how the entries should look, and about COM in general.


> * The register method is pretty simple but I don't understand where the
> ...ExternalLibrary moduleFileName: nil.. gets the server path string? Do
> I have a messed up installation perhaps?

This could be a result of the FileLocator changes; there were some growing
pains after they were introduced, and this might be a lingering bug.


> * Is the proper Dolphin protocol to start a particular image (not just
> the last opened image) in a COM object registry to pass a path to a
> particular .img file? It seems this is a better way to do it rather than
>   relying on the default image. (btw-I tried to do this, but it puked
> w/o even trying to start that specified image)

Early on, I got burned (no permanent damage, but, the lesson stuck) by the
default image feature, and think it should be eliminated.  With that bias
confessed, have you: (1) checked the syntax for specifying the path and
command line arguments in the registry entries; (2) made sure you really
have the correct paths to executable and image?  Spaces in the names might
need to be replaced with % or some other convention, single vs. double
quotes, etc????

In short, my recommendation would be that you consider having the
development image register servers on the fly, and leave the auto-start
stuff to your deployed apps.  That will work.  My other recommendation is to
buy Dolphin: it's a great product.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> Eric,
>
>
 ...


> I've never tried to register and auto-start a development image; instead, I
> have development images register servers when appropriate.  My deployed apps
> gets registered via a .reg file as appropriate.  


Guess I'm a little confused. What does "development images register
servers when appropriate" mean? Perhaps you've discussed this on the
wiki and you can point me to that.

...
 

I think I got by the issue. I had two installations, but the one I was
using was not the registered one. I removed both installations and
reinstalled once. Then moved all my images to the new installation. Then
when I registered my ..Imp subclass, the path was right.

This at least got me by the LocalServer32 reg entry confusion.


....
>
> Early on, I got burned (no permanent damage, but, the lesson stuck) by the
> default image feature, and think it should be eliminated.  With that bias
> confessed, have you: (1) checked the syntax for specifying the path and
> command line arguments in the registry entries;


yup

(2) made sure you really have the correct paths to executable and image?  


do I need to have the executable included in the path? I thought I just
specified the .img file path.

> Spaces in the names might
> need to be replaced with % or some other convention, single vs. double
> quotes, etc????

>
> In short, my recommendation would be that you consider having the
> development image register servers on the fly,


Same as my comment above... Could you elaborate more on this? Or point
me elsewhere? Example would be great.


> My other recommendation is to buy Dolphin: it's a great product.


I'm working on it. :)

thx

Eric

Eric,

> > I've never tried to register and auto-start a development image;
instead, I
> > have development images register servers when appropriate.  My deployed
apps
> > gets registered via a .reg file as appropriate.
>
>
> Guess I'm a little confused. What does "development images register
> servers when appropriate" mean? Perhaps you've discussed this on the
> wiki and you can point me to that.

The basic idea is that if you register a class factory from a running app,
then COM will come to that class factory to get new instances of the
component.  Failing that, COM will go to the registry to see if there's a
server it can start.  If I'm debugging, I manually register the class
factory and revoke it later; that way, I never have to worry about getting
COM to launch a development environment.  The details are thankfully hidden
under a few layers of stuff that is saved in my QuickCode file, or in the
startup code for deployed apps.

For details, see #registerClassFactory and #revokeClassFactories.  The
latter can be important because once registered, Dolphin will re-register a
class factory on startup.  Often that's what you want, but, I have faint
memories of a few problems that went away after revoking factories.

The COM page on the Wiki has some links that might help.  If you haven't
done so, you might want to look at the (don't expect much) newCOMer example.
If you don't have a copy, get Rogerson's book - it's a great resource.



> > That could be glitch in the registration code.  IIRC, the sequence was
that
> > I got everything working with .reg files etc., then OA added more
> > sophisticated support, but, I never adapted to it because I found DCOM
to be
> > unusable and as a result would have little to gain by a slicker way to
> > register apps with COM.  As it is, I have a few key things that already
have
> > working installers built "the hard way" but the work is done.
> >
> > If the registered .exe path looks wrong, you might try editing it (with
> > great care of course!) using regedit.  Rogerson's "Inside COM" is a
great
> > source of info about how the entries should look, and about COM in
general.
> >
>
>
> I think I got by the issue. I had two installations, but the one I was
> using was not the registered one. I removed both installations and
> reinstalled once. Then moved all my images to the new installation. Then
> when I registered my ..Imp subclass, the path was right.
>
> This at least got me by the LocalServer32 reg entry confusion.

Andy and Blair, please consider whether this might be an unintended side
effect of registering the .img type with "Dolphin" - something that I
respectfully submit cannot be done because a particular image is meaningful
only with its corresponding version of the VM.  I long for return to the
"old days" of a small .exe that loads the image close to it, or by path if
somebody wants to work at it.  Having the VM as a COMponent is great,
because each loader knows which VM/GUID to request, so one is then free to
copy the loader anywhere on disk, and stuff like this won't happen - at
least that's my experience.


> do I need to have the executable included in the path? I thought I just
> specified the .img file path.

Well, again I ask which VM loads? My fear is that we've been protected by
the fact that we really have only one version of Dolphin with the Windows
Installer shortcuts and registered document type.  When you have both D5 and
D4 on your system, what then?  IMHO, it's an accident waiting to happen.

Getting back to your problem, is COM aware of the registered file types?  It
might not be, and I would argue that it shouldn't be.  Try specifying the
path to the executable too, and things might improve.  However, if it's my
development image, I don't want it loading without my approval.  That's in
large part because of the way I manage backups, and you might not be as
sensitive to it.  If something decides to load on its own, I can find myself
wondering whether my backup gizmo is trying to save me from a mistake, or
simply confused because I double clicked on the wrong kind of file and
something is artificially marked as changed as a result.


I'm simply thinking of the % characters that sometimes appear in URLs.  I
also had a problem with some older MS code (TweakUI or something like it)
that refused to run, and it turned out to be because of a space in a file
name.  In fairness, it was a while ago, but, it's something to consider when
tracking down problems.  My hunch is that COM has no idea what to do with a
.img file as an excutable, and I approve if that's the case - it shouldn't
be making decisions like that on its own.


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:


thx.. I'll give it a whirl. I'm also trying to do some testing by
creating an internal implementor for my COM calls. That has promise.

You mention Rogerson's book, Inside COM....In reading some reviews on
Rogerson's book on Amazon, the general consensus seems to be that some
C++ knowledge is good and that Rogerson's book is good for a COM starter
(like me).

But I have and read Chappel's book. That's really high level. And since
Chappel's book is clearly for the beginner & Rogerson's is also for the
beginner, would you consider Rogerson's book a complement or substitute
for Chappell's book? IOW, IYO would I benefit much from having
Rogerson's in addition to Chappell's? I'm not a great C++er.

Another factor is that COM is only a vehicle in our project. What we're
really after is to build an OPC framework in Smalltalk (ideally,
although we're not averse to C++'ing it) for a product. OPC is a big
world as well. So I'm trying to balance my time here.

Eric

Eric

"Eric Winger" <[hidden email]> wrote in message
news:[hidden email]...
If you are still experiencing a problem with this, then I have two
suggestions:
1) Check that marshalling code is available for the interfaces you are
trying to implement. The symptoms of marshalling code not being available
are usually that the server is started, and the class factory invoked to
create the object which is then sucessfully queried for the required
interface, but this never makes it back to the client. In order to perform
out-of-process COM calls it is necessary to have "marshalling" code
available so that COM can serialise the calls for IPC. This requires that
either the interface be "automation compatible" (basically this means it is
VB compatible and uses only the automation datatypes such as VARIANT, BSTR,
LONG, etc), in which case OLEAUT32.DLL can do the marshalling use
information from the type library, or that a custom marshalling DLL has been
built. The latter involves running a C compiler against the *_i.c and *_p.c
output that MIDL tool creates from the IDL file. You can use the OLEVIEW
tool to find out is a marshalling DLL is registered for the interfaces.
2) If the server is starting and marshalling code is available, the class
factory may be failing to register or failing to create an instance. Set a
breakpoint or two in Dolphin's class factory code (e.g. at the start of the
COMClassFactory>>register and COMClassFactory>>CreateInstance:etc) and then
attempt to create the object from your client again. On hitting the
breakpoint Dolphin will pop a walkback in the normal way, and you can then
invoke the debugger and debug through. The same technique can be used for
debugging one's COM objects by inserting 'self halt's in the implementations
of the

As Bill suggests it is sensible during development to pre-start a
development image in which the class factories are registered and then let
that service automation requests for the objects. Registering a factory for
COM server class need only be done once and there should be no need to
revoke the class factories.

> I got to looking in the LocalServer32 registry entry that's created when
> doing COMInterfaceImp subclass | register. I have two installations of
> 4.0 trial (I'm hoping to buy one soon -upgrade my 3.0 license-, if these
> tests pan out) One in c:\Program Files\Dolphin 4.0 & one in
> c:\winnt\profiles\....). The funny thing is that even though the image
> I'm running is out of c:\winnt\...., the LocalServer32 registry entry is
> "c:\Program Files....".

The LocalServer32 registry key should be pointing to Dolphin.exe.

> Questions:
>
> * The register method is pretty simple but I don't understand where the
> ...ExternalLibrary moduleFileName: nil.. gets the server path string? Do
> I have a messed up installation perhaps?

Try executing it in a workspace. It evaluates to the path of the host
executable, which in a development image is the Dolphin.exe which started
the image.

> * Is the proper Dolphin protocol to start a particular image (not just
> the last opened image) in a COM object registry to pass a path to a
> particular .img file? It seems this is a better way to do it rather than
>   relying on the default image. (btw-I tried to do this, but it puked
> w/o even trying to start that specified image)

AFAIK the LocalServer32 key cannot be used to pass arguments to the server.
In Dolphin 5 (which can implement in-process components) the 'development'
registration for a server includes an 'Image' key which specifies the
development image to load. The runtime registration does not require this
because the image is bound into the DLL.

> Side question..
> * I didn't see anything specific in the o-a web site about how licenses
> for the Professional suite is handled. On a machine, developer or site
> basis? Say we have 3 developers wanting to work on with Dolphin? Do we
> need 3 licenses?

Yes. Essentially Dolphin is licensed on a per-user basis. Each user must
have a license, but can install Dolphin on multiple machines. A single
license may not be shared or used concurrently by different users.

> * Further aside, am I safe to assume that if I want to use a license for
> my own development at home (mostly to further my work development) then
> I would need a seperate license? As opposed to reusing a work license?

Assuming that the owner of the license is your company, then yes you can use
it to carry out further development for that entity, but not (strictly
speaking) for a different entity (such as yourself).

Regards

Blair