Hi, thanks for your quick reply. I found the culprint while writing this
email :-)
Generally, what I'm trying to do is to make a very basic package to
create and communicate with COM components on Windows, mostly as an
exercise :-) I found this library: http://disphelper.sourceforge.net/ as
a great start, so you don't have to fiddle with OLE/COM headaches.
The problematic function in C is defined as:
__declspec(dllexport) void CallMethod(void* myObj) {
...
}
It takes a pointer to a COM object, which was previously returned by
__declspec(dllexport) void* CreateObject(char* szProgId) {
...
IDispatch * myObj = NULL
...
return &myObj;
}
So, CreateObject() creates COM object and returns a pointer to it,
CallMethod() takes this pointer and tries to communicate with it.
My error was in returning a pointer to a pointer ... since IDispatch *
myObj = NULL was actually hidden in a macro and I missed its true
definition, huh.
I'm running Pharo from PharoLauncher directly on Win10, without
cygwin/mingw. For DLL I use Visual Studio 2019. I was not sure whether
the pointer survives from one FFI call to another, or how Pharo
loads/unloads DLLs - but it works as expected.
Thanks again and best wishes,
Tomaz
------ Original Message ------
From: "Guillermo Polito" <guillermopol...@gmail.com>
To: "Tomaž Turk" <tomaz.t...@ef.uni-lj.si>; "Any question about pharo is
welcome" <pharo-users@lists.pharo.org>
Sent: 11. 09. 2019 10:29:34
Subject: Re: [Pharo-users] uFFI ExternalAddress challenges
Hi Thomas,
Can you share more about the definition of your CallMethod function in
C?
From the uFFI point of view the binding looks ok…
How are you opening Pharo? From the command line or the pharo launcher?
Are you on cygwin/mingw? One other possibility (since you’re playing
with C libraries) is to launch Pharo inside a gdb/lldb so you can check
the reason behind the error when it crashes.
Keep us posted,
Guille
