|NOTE: This is just for discussion purposes and to continue working towards a possible means to impliment some better support. It is not a *fix*, its not a complete idea, its just throwing some things around. If some people don't like it, they can go frack themselves. That said.|
Heh Nick.. Is there something in the Lua interfaces or LuaCOM for "messages". I.e., redirection of system messages to the dll?
Been doing more reading. There seems to be some implication that one has to *somehow* redirect messages to the script engines for them to handle events. Internally, once the messages get there, it seems that LuaCOM handles interfaces for the events by keeping a table containing the script entry points and event IDs or something, so that when it gets a message containing the ID, it can call the needed function. However, for that to work the message loop in the host has to be able to redirect anything it gets out of the loop, in your case the main message loop where this stuff is handled, to the script engine/luaCOM interfaces. I am having some trouble tracking down just how the frack that works though... It might require asking each script engine if its has a table entry for the IID of the object and event fired, then passing the message to it, or something...
As usual, the assumption seems to be that if you are trying to do this, you already know how to do it, or your using something that does it automatically. Closest I have found so far are some code changes that would allow an MFC application to support late binding of COM objects "within itself", along with events, by patching in ATL functionality. Its about 30 lines of code in various places, but its also none too clear, at least to me, how it keeps up with multiple objects (I suspect that requires even more code to impliment and interface/object container, like LuaCOM uses). The part in the article about late binding tends to go something like, "Do this, do that, add this code, impliment blah, zip, bang, presto!" Presumably, if you have a clue what the first part of the article was doing and how to correctly support multiple objects within that framework, then the "impliment blah" bit makes fracking sense.
Why the bloody hell can't people just provide real code examples instead of being so damned obtuse that they assume everyone already knows everything they do? Its also not quite what I was looking for, since it impliments the creation, messaging and object handling client side, rather than taking advantage of existing script engine features. Though that might not be a bad thing, given that it would be generic to "all" engines, with some code to keep track of the message IIDs, who they belong to and what engine+script function to call when they happen. No worse, in theory, than what you already do when checking for the presence of callbacks in plugins.
If you want to take a look (though I am still trying to find clearer information):
You will note that it also has the disturbingly stupid choice of using HTML and IE to "prove" that the final product works... Yeah, real damn useful... :( Though, I get the impression that its only instancing the COM object that impliments the linking, since its easier than, I don't know, actually including it in a fracking application that also shows how to get the scripting to work. Sigh...
--> bangs head against the wall.