Hi Blair,
With any luck, I've completed another external connection. It took a couple
of weeks to track down what turned out to be an incorrect file name =:0
This was difficult to find because: (1) no source code for the DLL; (2) the
DLL appears to incorrectly return true even if it can't load the named
file(s). The result was that I was getting weird floating point problems in
subsequent function calls; the problems were, of course, due to
uninitialized data structures.
Ok, so what's this got to do with Dolphin? One way it might impact Dolphin
is via VC++'s (I'm guessing keywords) bool/true/false. Is there any chance
that they would confuse Dolphin? I know I said I didn't have source code
for the DLL, and that's true. But, along with the DLL came some C++ code
for using it, and I adapted that to be more generic and packaged it in a DLL
with a few C-callable functions. By the time I was done creating my wrapper
DLL, there was a mix of TRUE/true, FALSE/false, and BOOL/bool.
At one point, I tried (largely out of desperation) making the sample code
into an MFC Automation server. Then I ran the app to register it and
generated wrapper classes in Dolphin. However, inspecting
IGeneratedClass new
gave a walkback. I remembered hitting something lik ethis before and found
an old post in which I proposed the following fix:
!AXTypeInfoAnalyzer class methodsFor!
onTypeInfo: piTypeInfo
"Answer a sub-instance of the receiver of an appropriate class to wrap
the <ITypeInfo>, piTypeInfo, referencing the correct unique
<AXTypeLibraryAnalyzer>
instance that represents its containing type library."
| contain answer lib |
#wksDangerous. "Added #asParameter"
contain := piTypeInfo asParameter libraryAndIndex.
lib := contain key.
answer := (AXTypeLibraryAnalyzer onTypeLib: contain key)
typeAnalyzerAt: contain value.
lib free.
^answer
! !
!AXTypeInfoAnalyzer class categoriesFor: #onTypeInfo:!instance
creation!public! !
It worked here too.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
