|Umm. It would have to work, otherwise any and all script languages that use these sorts of things would fail. As I understand it, if something isn't explicitly trapped in your programs loop, it instead gets passed on to the OS, eventually the OS passes it to the object that it belongs to. That is what the "connect (event, function)" stuff does. It explicitly binds the event to the address of the function inside the script, so that unless you intentionally intercept the event and prevent it, the event automatically calls that entry address. Mind you, I have been wrong before, but I don't think, short of intentionally preventing it, you can stop a system like this from working. Your application isn't *actually* sending the event to the function, its more like:|
Event happens->OS recieves->OS informs main application->if returned, OS informs subwindow/object->if returned, OS informs the sub-sub window/object->etc., until it either fails to find the function, the right function is found, or something else handles it and tells the OS to stop trying to find the correct owner.
But, people have successfully used LuaCOM and its connect function for events right? Or am I wrong there? If that works, then why should an integrated wx.connect be *less* possible than luacom's version? Wouldn't the previous one create the same conflict (or actually logically a worse one), if one existed?
Shouldn't be hard to try it out and see anyway.
As I said, in theory, the only lines that need to be changed in any of the samples to test it is the one for creating the main window. The one that uses wx.NULL as the first argument, instead of an existing frame. Using NULL *will* crash the client and engine. I tried it with Python. lol But, when I tried it we didn't have GetFrame to return an existing window, nor was I aware of the connect function for events (since I had bits of the details on how it all worked wrong). Now, I would say that the odds of it working is probably 90%, with the other 10% being maybe some code to make sure the engine is passed the un-trapped events from the client, so it has a chance to deal with them.
But, I don't think that is likely necessary. Your forgetting something. If I do:
myframe = wx.frame(world.getframe, ...)
myframe becomes a *child* of the main mushclient window. Since its a child of that window, any events not handled by the parent are passes in turn to all children, which *should* include the new window we just created. Events going the other direction are, I would assume, going to get handled correctly as well, since they are calling functions in Mushclients environment space, and I assume the engine is using that space for its own operation. After all, if it wasn't, the client would freeze in a script loop. Since both engine and new objects are in the event loop of the client already... the only issue is if the client accidently prevents them from going where they are supposed to, right?