Actually, the whole problem comes down to that message pump. I have explored a bit and found that there is "apparently" a means to mix some ATL into MFC apps to "bridge" this, since MFC's standard way to handle such things is to *only* allow early bound events, via *its own* internal managers. Obviously, this causes a huge headache when using any sort of scripts, since a) the scripts are late bound, and so are any objects they create. This frells communications in both directions, since the MFC pump recieves the events going both directions (if I understand the issue right) and then has no clue what they belong to, or how to get them there, so just ignores them. This may even be why things like "Destroy()" on some objects are not automatically called, since, while the script knows its gotten a "I am unloading you" event, the object doesn't get one, so the script dies, but the object remains in memory, with nothing connected to it. But, that is only a guess, so I am not really sure what is going one in those cases.
Basically, the only fix is so arcane that I have been hunting for it for years and never quite finding a clear piece of example code that shows how to do it, or rewriting the client in something that doesn't tie your hands and feet to a chair, then beat you when you want to handle late bound objects. It might simply be easier to port to something like mono, which exists for Windows as well, and how that it, and its compiler, is fast enough to produce an equivalent client, and would also make things work in Linux and others as well. But, doing that means translating all the blasted MFC calls into code that does the same things as the current client.
Basically, there are a huge number of things only solvable by either fixing the big hairy ball of problems with late binding and objects that MFC creates, or by bypassing it using stuff like UDP. The only problem being, you can't even do the later if the 0bjects you are making are done via wxLua, or the like, since you *still* can't handle events internally to the Lua system. Only stand alone objects, compiled as their own applications, can use UDP to return events, since they are the only thing able to handle their own events to *see* them, and respond via that method. Others, including ones from .dlls, can't do jack, probably even with their own events internally, since they rely on Mushclient's sealed and inaccessible message pump to *tell* them something happened.
Mind you, there is one other solution. Bloat the client with code to provide the windows, buttons, images, etc., using *its* internal pump and support, assuming you can even do that right in MFC, since, I presume, even cloned from known internal objects, those would still be late bound and therefor not in the pumps support structure... I don't know who it was that originally thought, "Heh, lets make something called MFC, so its *easier* to code.", but they must have also invented child proof bottle caps. lol |
![[Go to top]](/images/gototop.gif){kind=small}
top