|Actually, I am not sure how well Lua or others do handle this. See.. The problem is that when you create a window it has to be tied to something, but most cases (I tried it in python once) you *can not* define the windows as a top level application window. I.e., if you use NULL for the parent, it will crash both the script and Mushclient. So.. the only choice is to use Mushclient's window as the parent.|
This is where the problems start... Instead of the script recieving the events from the object, Mushclient does. Only Mushclient has no clue what to do with them, so simply ignores them. The result is that any events from that window, or any control placed on it, fail to do anything. As far as I know the only way this can work, even in Lua, is to run the script stand alone, instead of through Mushclient, but then you have an entirely different mess.
Now, Nick. This isn't a flavor of the week thing I am talking about. This is ***exactly*** how IE handles objects. There are only two ways to instance and object. Early and late binding. Early binding links the ActiveX objects functions directly into the program at compile time, so the compiler can directly connect a function or subroutine to the event message stream for the application. The other method is late binding, which you *can't* bind events with. All web controls in IE which are declared using CLSID's, or instanced through createobject in things like VBScript, are late bound. This means they "must" have a bridge to connect the events they generate to the instanced object. IE has a built in bridge and VBScript even has a command called GetRef, which works by simply tying the "event" IE is already aware of from when it instanced the object to a function:
set Window.close = GetRef("IClosed")
JScript uses something much closer to what the example I gave does:
However, *neither* of these will work with Mushclient, because Mushclient does not impliment an ATL bridge that is compatible with the functions in either script language.
So.. I have to question the idea that something MS uses to impliment basic functionality in IE itself would get changed so it no longer works in some later version. ATL is the ActiveX Template Library. The functions used for "both" of these tricks are standard for everything from Internet Explorer to, in the later case with iaxwin... their own form designer in all their compilers. Heck, for that matter, their IDE wouldn't work right without a similar bridge system, since it allows you to "test" components without compiling the actual code in some cases, which would be quite impossible otherwise.
In any case, the point here is Lua and others can handle events for objects they create "when running in a stand alone environment where ***they*** are the top level application window. When running as a script engine for something like Mushclient, the top level already exists, so any attempt to create such a window will crash the engine and the client its tied to. But, if you use Mushclient as the top level window when creating a new one, it is "Mushclient", not the script that recieves event messages. This can only be fixed by doing the same thing IE does when dealing with this sort of problem and using an ATL bridge to intercept and connect the events to the script function. Its also the only way you can add unknown post-compilation objects into "any" application, no matter what language, and have them respond to events. Lua and others have their own bridges, but they only work when "they" are the top level application window, so they are already receiving the events.
Without a bridge, they couldn't work either, since obviously with a just in time system like scripts run with, there is **no** way to pre-define what an object is so that its events can be handled. That is why you can't place a line like "dim MyObject WithEvents as SomeObject" in vbscript. All scripting objects are late bound, even in Lua. Yet, somehow they manage to handle them. The only method I have found "anywhere" that does that is an ATL bridge, since it requires using the ActiveX atl.dll to trap the events and redirect them to the script functions. If I am wrong, someone show me an example of creating a window with a button in Lua (or anything else) inside a plugin, where the button or the window actually work right. It still wouldn't solve the problem of anything from existing controls to stand alone applications, but it would still suprise me a lot, given I already tried once and failed completely with Python.
Now, as for if you can use ATL with MFC... Why the hell not? MFC already uses ATL internally to work at all. The only thing you are doing when using the ATL library, instead of MFC, is cutting out one of the middle men. In fact, half the tricks in the toolkit of most programmers for professional development involves using lower level libraries to alter the behaviour of things like MFC. Sorry Nick, but I personally think you have far more to worry about when it comes to the possibility that MS will change the high level, miles away from the core dlls, MFC implimentation than the critical components like ATL, which if changed would break everything from MFC itself to their precious Explorer. Your being imho paranoid.
Sorry for the long and sightly ranting post, but I have done a lot more research on just why events can't be handled right in late bound objects and what the "only" solution for fixing it, which is discussed a lot on Microsoft's own site though sans any useful examples of how to use it (I get real tired of that), than you have. The fact that I don't know enough C++ to successfully impliment "Hello World" doesn't alter the fact that I do know something about programming in other languages and do have a fair understanding of what is going on in this case. Hell, I have been trying to find solutions to these two issues for over three years. I don't need to prove that it works. IE already uses an implimentation of it, as do many other application. I also know that the usermode trick, despite its obscurity, has at least a dozen $200+ applications floating around that impliment it, not including every form designer made by MS themselves for their own compilers. I wish I could design a test example to prove it, but.. Right now I have only a version of VC++ 4 and its on a machine that isn't working right by even the most limited definition of "working". :(