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 |
"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 |
Free forum by Nabble | Edit this page |