Extension Modules > COM
Couple Api ideas for embedding
dzzie:
If it has something like RegisterCallBack for you to set event handlers from passed in function pointers then it would be hopeful.
Support:
Take a look and the IUP (PUI) SB extension module. All events go through a common message handler function. IupLoopStepWait() In DLLC the SB script functions are called directly. With my C extension module for IUP it returns back to SB on an event and i do an ICALL with the address of the script function. I have a set of C callback functions that IUP calls and sets global variables I reset after access in another call if needed.
Verhas:
Wow this is impressive what you do with this interpreter. I am amazed.
As for the API suggestions my 2cents:
namespace lookup hooking is an interesting approach. The issue is that ScriptBasic was not designed to support namespaces. This is only a naming trick. The namespace:: prefix becomes part of the name and that is it.
--- Code: ---scriba_registerNative(pProgram, "myFunc", &myFunc_handler)
--- End code ---
is also an interesting idea, but it can actually be solved defining an external module. Note that the external module can be "part" of the embedding application. It does not need to be a DLL (or .so in UNIX). It can be statically linked to the application and be available to the interpreter so it can call the method. Note that the function pointers are defined in a table for the modules (as far as I remember, I have not touched it for 8 years now). In that table there is a
--- Code: ---"myFunc" , &myFunc_handler
--- End code ---
part that defines the function entry point and the associated name. It is true that you can not have different associations for different pProgram objects. It is static.
dzzie:
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.
--- Code: ---#define besSUB_START besFUNCTION(bootmodu)
#define MODULE_INITIALIZER "bootmodu"
/* modumana.c call the module initializer function */
FunctionPointer = modu_GetModuleFunctionByName(*ThisModule,MODULE_INITIALIZER);
--- End code ---
so if functionPointer == NULL then maybe secondary check something like
--- Code: ---sprintf(buf, "%s_bootmodu", (*ThisModule)->pszModuleName)
FunctionPointer = modu_GetModuleFunctionByName(*ThisModule,buf);
--- End code ---
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
--- Code: ---'sb code
ConnectEvents(objPtr, "objName")
sub objName_Clicked
--- End code ---
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 :)
Support:
Great progress Dave!
Let me know if you need some help with testing.
--- Quote ---Currently if more than one internal extension is compiled in besSUB_START and friends would conflict is only problem I see.
--- End quote ---
Each internal extension should be compiled into its own object library. I assume SB skips the whole DLL handshacking routine knowing that it's static linked. (no load/unload stuff going on or version checking needed) Peter would have to validate my understanding if it's true or not.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version