Using an ActiveX Program from Dolphin on Windows 95...

I have to interface with a third party ActiveX application in my program.
The ActiveX stuff works fine in my development environment, and the runtime
on a Windows ME, and Windows 2000 machine.  However I have an end user
running Windows 95, and he gets an "HRESULT Error: Interface not registered
(FACILITY_ITF)" error.  Normally I would say that the ActiveX program was
not registered.  However he _can_ access the application from Excel VBA
code.

The Excel code (this works on his machine and mine) uses:
==========
Dim CC5 As Object
Set CC5 = CreateObject("CHEMCAD.VBServer")
==========
In Dolphin (both of these work on my machines, but not his) it is getting
the clsid like this:
==========
^CLSID fromString: '{2B03C5E1-25B6-11D4-BBD3-0050DACD255C}'
but I also tried this (same problem on users computer):
^CLSID fromProgID: 'CHEMCAD.VBServer'.
==========

I even ran regmon and compared what Excel was doing vs what my application
was doing.  I did not see any significant difference.

Has anyone experienced anything similar?  Is this a known quirk?  Any work
around?

Chris

Chris,

> I have to interface with a third party ActiveX application in my program.
> The ActiveX stuff works fine in my development environment, and the
runtime
> on a Windows ME, and Windows 2000 machine.  However I have an end user
> running Windows 95, and he gets an "HRESULT Error: Interface not
registered
> (FACILITY_ITF)" error.  Normally I would say that the ActiveX program was
> not registered.  However he _can_ access the application from Excel VBA
> code.

Is this a situation with an orphaned device?  I had a really nice PCMCIA
modem that worked on Win95 and is a black hole on anything newer, so I know
it can happen.  Otherwise, have you talked to the user about either
installing Win98 on the machine (that's assuming it's still commercially
available), or (gasp) getting another machine?  My thoughts on Microsoft's
strategy are not secret, and I am not suddenly defending them.  However,
Win98 has been around for years, is inexpensive, and is generally a huge
improvement on Win95.  I could point out that Win95 is no longer supported,
but then, well never mind :)  Maybe _you_ should mention Win95's status to
the customer??

Assuming again that it's one box, has the customer thought about what will
happen when the machine finally quits?  It would be wise to try to get a
newer box running.  That might work :)  It also happens to be good advice.

Aside from orphaned hardware, a big reason for clinging to Win95 would be if
the customer has a large number of machines, but this sounds like a single
box???  Since one "minor upgrade" for our hospital was going to cost
$2,000,000(!!!), I can understand what might happen if the customer has a
large installed base.  Delta Airlines took a _long_ time to finally
"upgrade" (read replace, as in buy all new stuff) their ticketing
workstations, and they stalled because of the cost.  In their case, I think
it was roughly 20,000 machines, which adds up fast.

My point is that it might be time for a cost/benefit discussion with the
customer.



> I even ran regmon and compared what Excel was doing vs what my application
> was doing.  I did not see any significant difference.
>
> Has anyone experienced anything similar?  Is this a known quirk?  Any work
> around?

I had a similar kind of problem earlier this year.  IIRC, it turned out to
be a popup message that was interfering with self-registering a Dolphin COM
DLL, so the component in fact was not registered.

The other problem I had was trying to get Dolphin apps called from Apache.
I finally ended up writing my own (quite limited) web server because my
problem was only occuring on win2k test machines; the production server was
happy.  I doubt that Win95 is capable of causing problems like that.  Just
the same, below you will find a few desperation fixes - no promises or
warranties.

Other things that come to mind: which version if IE is the offending machine
using?  Does it have DCOM for Win95 installed?

Have a good one,

Bill

-------------------------------------------

!COMInterface class methodsFor!

onCLSIDDefaultFactory:clsid
 "Try CoCreateInstance() vs. first asking for the factory."

  | pUnk |

 #wksDangerous.
 pUnk := self newPointer.

 OLELibrary default
  coCreateInstance:clsid pUnkOuter:nil dwClsContext:CLSCTX_LOCAL_SERVER
riid:pUnk iid ppv:pUnk.

 ^pUnk
! !
!COMInterface class categoriesFor: #onCLSIDDefaultFactory:!public! !

!COMInterface class methodsFor!

onCLSIDLocalOnly: aCLSID outerIUnknown: pUnkOuter hostName:hostNameString
licenseKey: licenseString
 "Answer an instance or subinstance of the receiver on an instance of the
specified COM
 component class, instantiated by its registered server, with the specified
outer (controlling)
 unknown, on the specified remote host, and using the specified license
string (or nil if not
 licensed)."

  | dwClsContext hr pServerInfo pUnk pFactory |

 #wksDangerous. "Wondering whether problems are due to too broad a
context???
 dwClsContext := self createContextFlags."
 dwClsContext := CLSCTX_LOCAL_SERVER.
 (hostNameString notNil and: [hostNameString notEmpty]) ifTrue: [
  pServerInfo := COSERVERINFO new.
  pServerInfo hostName: hostNameString.
  dwClsContext := dwClsContext bitOr: CLSCTX_REMOTE_SERVER].
 pFactory := IClassFactory newPointer.
 OLELibrary default
  coGetClassObject: aCLSID
  dwClsContext: dwClsContext
  pServerInfo: pServerInfo
  riid: pFactory iid
  ppv: pFactory.

 "Successfully retrieved class factory - now ask it to make an instance"
 pUnk := self newPointer.
 hr := pFactory CreateInstance: pUnkOuter riid: self iid ppvObject: pUnk.
 hr < 0 ifTrue: [ | license |
  "Failed for some reason, perhaps it needs a license"
  hr = CLASS_E_NOTLICENSED ifFalse: [^HRESULTError signalWith: hr].

  pFactory := pFactory queryInterface: IClassFactory2.
  pFactory isNil ifTrue: [^HRESULTError signalWith: hr].

  "If a license key was not supplied, then try and get a runtime license"
  license := licenseString isNil
    ifTrue: [pFactory requestLicenseKey]
    ifFalse: [licenseString].
  pFactory
   CreateInstanceLic: pUnkOuter
   pUnkReserved: nil
   riid: pUnk iid
   bstrKey: license
   ppvObject: pUnk].
 ^pUnk! !
!COMInterface class categoriesFor:
#onCLSIDLocalOnly:outerIUnknown:hostName:licenseKey:!instance
creation!public! !


!COMInterface class methodsFor!

newLocalOnly
 "Answer a new instance of the receiver and associated component instance
 (created via CoCreateInstance)."

 #wksDangerous.
 "^self onCLSID: self clsid.
 ^self onCLSIDLocalOnly:self clsid outerIUnknown:nil hostName:nil
licenseKey:nil."
 ^self onCLSIDDefaultFactory:self clsid
! !
!COMInterface class categoriesFor: #newLocalOnly!instance creation!public! !

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

...
> Win98 has been around for years, is inexpensive, and is generally a huge
> improvement on Win95.  I could point out that Win95 is no longer
supported,
> but then, well never mind :)  Maybe _you_ should mention Win95's status to
> the customer??
...

They already have plans to migrate to XP in the near future.  However I did
not want to wait for that before completing the project. ;)

It turns out that the problem was a difference between early binding (my
app) and late binding (the Excel example).  A type library was not
registered.  Apparently early binding needs more info from the registry.
After I did a clean install on a new machine, and reproduced the problem I
was able to register the type library and it worked.

Chris