Hi Peter
thanks for the ideas and the great code base !
The internal extension is working well. Currently if more than one internal extension is compiled in besSUB_START and friends would conflict is only problem I see. I think this will be easy to work around by prepending module name to it.
#define besSUB_START besFUNCTION(bootmodu)
#define MODULE_INITIALIZER "bootmodu"
/* modumana.c call the module initializer function */
FunctionPointer = modu_GetModuleFunctionByName(*ThisModule,MODULE_INITIALIZER);
so if functionPointer == NULL then maybe secondary check something like
sprintf(buf, "%s_bootmodu", (*ThisModule)->pszModuleName)
FunctionPointer = modu_GetModuleFunctionByName(*ThisModule,buf);
seems like should work. actually in further thought..maybe it wont I was thinking of preprocessor name, pszModuleName is probably taken from declare i havent step breakpoint yet to check for sure. (also forgot to mention above I also had to disable strcat for dll extension to module name for it to work from exe.) Some variation of this concept will work anyway though.
I also found a good article on x64 COM.
http://mariusbancila.ro/blog/2010/11/04/32-bit-and-64-bit-com-servers/Have not had a chance to look at the IUP yet except glance. Looking into IConnectionPoint maybe interesting experiment to see about how to connect call back events from COM back to SB event handlers something like
'sb code
ConnectEvents(objPtr, "objName")
sub objName_Clicked
then in C I imagine it works something like take objPtr, enumerate events object supports
then check script to see if objName_[event name] exists..if it does then handle the event and
call the sub manually when its hit. Interesting to think of the logistics of it anyway. Sinking events
may be required for IUP OCX as well from sounds of it.
More time to play on the weekend.
One thing I am not sure on is if I want to give script clients live object handles for them to passback
and me use blindly. Its kind of a bad idea. try catch and is null checks can handle some ok, but a random number
passed in could easily lead to memory corruption even if try catch kept execution going for now. Safer would be to
only pass back quasi handles I suppose and then validate them from an internal hash map to real value.
embedded clients who do things like AddObject to make object available to script would have to add to list as well.
Only down side is if a COM object returned another COM object, the script would not be able to use it now since
the manager would not be aware of the pointer being valid. (or script could be given access to register its own then
stability is all in their hands)
anyway i think the COM extension will be left for a while now. majority is done, will need to build out the other components
to circle back and start really using it to see what more it needs. One surprising thing, if a vb com object expects a byte type (VT_I1), it will accept a VT_I4 and .lvalue as long as value < 255. I suppose not so surprising since I think the value is a union, but still seems like it is being kind with an auto conversion accepting different type in background. I will have to test some ATL based clients to see if they are as kind.
but so far so good