Bug: AXDispatchImpAbstract GetTypeInfo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug: AXDispatchImpAbstract GetTypeInfo

Bill Dargel
Is this possibly a bug? Proposed patch below.

After adding a new method to the interface in a type library, was running into a
DNU error here. After much debugging, came up with the indicated fix. Seems that
it was expecting to have the actual COM interface in "piTi", when it had the
wrapper. With the applied patch, things got further but still wouldn't work end
to end from the VisualBasic client. Using Dophin 4.0 on Windows 2000.

As I recall, by exiting Dolphin and restarting, things started working! But then
this method wasn't being called at all. (A halt in it was never hit). So in
retrospect, I might be totally off on there being a problem with this method
(since I was apparently getting to it under weird circumunstances), but it sure
looks like the implementation of #typeInfo:ifNone: will return some kind of
AXTypeInfoAnalyzer. Any thoughts?

Stop the presses!

After sitting on this message for a few days, I found a new repeatable situation
which hits this method and the bug. When an automation error is returned in
HRESULT to the VisualBasic client, it asks for type information from
ISupportErrorInfo. If the error was E_INVALIDARG, which VB apparently translates
into its own error number, then that's the end of it. But if the error was
E_UNEXPECTED, which VB doesn't translate, then further QueryInterface calls on
IDispatch occur, and then it hits the bug in GetTypeInfo. My workaround seems to
take care of it, so I'm more convinced today that this is a bug.

Brings up side question though. If a new method is added to an interface in a
TypeLibrary, does one have to exit Dolphin and restart to make use of it?
(Dolphin is an automation server here). Or is there something else that can be
done? Am I just too used to the malliable, dynamic nature of Smalltalk, and need
to come to grips with a longer cycle when it comes to working with COM
interfaces? (As you might guess, I'm still pretty new to COM stuff). Any insight
would be appreciated.

-Bill


!AXDispatchImpAbstract methodsFor!

GetTypeInfo: itinfo lcid: lcid pptinfo: pptinfo
   "Implement the IDispatch::GetTypeInfo() interface function.
   We don't need to provide any type information since this is an
   event sink, and the caller knows all about the interface.

   Implementation Note: At present we ignore the locale, which is permitted:
   'For classes that do not support localized member names, this
   parameter can be ignored'. (from Win32 help)"

   | piTi |
   pptinfo value: 0.
   itinfo == 0 ifFalse: [^DISP_E_BADINDEX].
   piTi := self typeInfo: lcid ifNone: [^TYPE_E_ELEMENTNOTFOUND].
   pptinfo value: piTi asParameter bytes.

"wod: added the #asParameter, since piTi was a TKindInterfaceAnalyzer
 which doesn't understand #AddRef, but its IDispatch does."
   piTi asParameter AddRef.

   ^S_OK! !
!AXDispatchImpAbstract categoriesFor: #GetTypeInfo:lcid:pptinfo:!COM
Interfaces-IDispatch!public! !


-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA


Reply | Threaded
Open this post in threaded view
|

Re: AXDispatchImpAbstract GetTypeInfo

Blair McGlashan
"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
> Is this possibly a bug? Proposed patch below.
> [...explanation of bug in AXDispatchImpAbstract>>GetTypeInfo:etc...]
>...

Yes, it sounds like it is. Thanks for the report and the patch (issue #659).

> ....
> Brings up side question though. If a new method is added to an interface
in a
> TypeLibrary, does one have to exit Dolphin and restart to make use of it?
> (Dolphin is an automation server here). Or is there something else that
can be
> done? Am I just too used to the malliable, dynamic nature of Smalltalk,
and need
> to come to grips with a longer cycle when it comes to working with COM
> interfaces? (As you might guess, I'm still pretty new to COM stuff). Any
insight
> would be appreciated.

It can be painful coming down out of the balloon :-). You could try
'<typelib instance> clearCachedAnalyzers', however this might not be enough
as there may be extant references to AXTypeInfoAnalyzers from that typelib.
More ruthless would be 'AXTypeInfoAnalyzer allSubinstances do: [:each | each
free]', which might work because it will cause even existing IDispatch
objects to re-establish their typeInfo instance variable. Even if you manage
to reset the server (Dolphin), most clients are expecting objects written in
static, dead, languages, and you may find they don't pick up the changes,
and the only way to make them do so is to restart. Even then one sometimes
has to "persuade" VB to pick up new definitions from a modified type library
by removing it from Project/References, shutting down, restarting, and
re-adding it. Perhaps this is OK within the spec, since a typelib with the
same GUID and version number is not supposed to change, but it is
inconvenient at development time.

Regards

Blair