Jan,

1) We (think we) got the dll problem.  It was STUPID but I don't understand it. 
The common factor for all of the machines it stopped working on were:

a) they weren't running MSOffice and 
b) the dll stopped installing on them when I added a method that can be used to manipulate E
xcel.

We installed Excel and .. voila. 

It looks like there is some kind of implicit dependency on MSOFFICE inside the control. 
I am suprised because my control is essentially an API.  Only if a method requiring graphica
l
output is called is a call to Win32::OLE made to invoke Excel - and if Excel isn't there tha
t
is the place to catch it.  I do use Win32:OLE::Const 'Microsoft Excel'.  Maybe this causes t
he 
dependency?  

Hats off to my colleague Steve who thought of it.  Shame his inspiration came after I spent 
hours
comparing RegMon output - and he sat down comparing all the versions of the explicitly 
dependent dll's.  

2) DispId's. Jan, many thanks indeed for the lesson. 

3) PerlCtrl and SAFEARRAYS. Jan, again many thanks for the lesson. I had
absolutely no idea that: return \@array; called (however indirectly)
through a PerlCtrl converted to a SAFEARRAY. I had thought that return
@array ; might be converted because it wasn't I went dowen the road of
explicitly making a SAFEARRAY in Perl and returning it. Got a whole lot
of code I can tidy up now! 

-----Original Message-----
From: Jan Dubois [mailto:jand@[...].com]
Sent: 27 August 2003 03:16
To: Roberts, Pete OGUK-OGCH/3
Cc: pdk@[...].com
Subject: DispIDs [was: Re: DLL suddenly fails to register on some
win2000 SP3 systems \]


On Tue, 26 Aug 2003 12:11:23 -0700, "Pete Roberts"
<pete.roberts@[...].com>  wrote:

> DispId's - I have used DispId's - I wondered what they were for!

OLE Automation doesn't actually call methods and properties by name, it
calls them by an integer index, called the dispatch id.  To call a method
by name, it first has to be translated to the DispID.  This means making 2
calls to the control.  Of course once you know the DispID you can cache it
and not have the additional overhead for the next call.

A compiler like VB can even cache the DispID during compilation: It
imports the type library and then only generates dispatch calls since the
ids are known at compile time.

However, when you don't explicitly assign a DispID in your PerlCtrl,
PerlCtrl will choose ids sequentially.  But the method and property
definitions are stored in a hash and not an array: they don't have a
defined sequence.  When you add an element, they may be enumerated in a
different sequence and *all* dispatch ids will change.  An already
compiled VB application will stop working correctly because it is now
invoking the wrong methods.  Only a reimport of the type library /
recompilation will fix this.

If you assign DispIDs manually, then adding a new DispID without changing
any of the old ones will not break binary compatibility.  SO you can
update your control and don't have to recompile your applications using
this control.

So it is a good idea to always assign DispIDs manually.

Cheers,
-Jan

PS: DispID 0 is special.  It is reserved for the "default" method of a
control that is invoked implicitly by VB when you do a value assignment
(as opposed to a reference assignment.  Let vs. Set).

_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs