Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ COM redux...
COM redux...

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Mon 26 Mar 2007 06:31 PM (UTC)
Message
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):

http://www.codeguru.com/cpp/com-tech/atl/article.php/c3573/

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.
Top
Posted by Nick Gammon   Australia  (23,121 posts)  Bio   Forum Administrator
Date Reply #1 on Tue 27 Mar 2007 09:50 PM (UTC)
Message
Quote:

Is there something in the Lua interfaces or LuaCOM for "messages". I.e., redirection of system messages to the dll?


I read the stuff in the Luacom page ( http://www.tecgraf.puc-rio.br/~rcerq/luacom/pub/1.3/luacom-htmldoc/ ) about making a message sink, but their example appeared to me to be done in a script that was already running - the example was updating a calendar. However the problem in MUSHclient is that the script engine is not running all the time - the C++ code generally is. The script engine is "brought to life" at well-determined times (eg. when a trigger fires)

I agree in principle with the CodeGuru article - in order to handle an event, first the server (that is, the thing that receives the event in the first place) must know that the script will handle it (hence some sort of registration process), and then the event must be passed to the script when it occurs.

The example given in the CodeGuru article is of detecting a button click, and then passing that to an COM object.

The first thing to consider here is that the Lua script engine is not, in itself, a COM object. It is merely some C code. If that C code happens to call LuaCOM, the LuaCOM DLL is one level away from MUSHclient. This is the general idea:


MUSHclient --> Lua DLL --> LuaCOM DLL --> Some COM object (eg. Calendar)


On top of that we have a problem, the example was a button click. Now I can make a dialog box, and if you click a button it can call a script. Exactly that happens in the Notepad's Global Replace function - which is implemented in Lua. However that is where I know in advance, and use the MFC framework, to handle that button click.

I believe from previous discussions you want to handle more general events (eg. a song change in Winamp). These are events that MFC may not even make available to me because they are not "registered" as part of the main application of being of interest to MFC, and thus would be discarded before my part of the program even gets them.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #2 on Wed 28 Mar 2007 07:00 PM (UTC)

Amended on Wed 28 Mar 2007 07:02 PM (UTC) by Shadowfyr

Message
Yes. There is some definite confusion on just what is happening in the context of something like we have here. Its possible, for example, that since LuaCOM is being registered in something that is in the same thread space as your client, it is automatically considered to be in the same message space as your application, thus to talk to LuaCOM, you might need to pass Mushclient the LuaCOM object, then pass the messages to "that". But, that won't do any good, since the LuaCOM object can't "wake" the script engine.

Worst case.. It might be necessary to ignore LuaCOM entirely, and instead use the MFC+ATL mix. In other words, have your client handle object registration, using its own create object function, enumeration of those objects in a container, and handle the event sinks, by keeping track of "which" script(s) requested a binding to an instanced object and waking them as needed. Its also likely safer, since Mushclient's own exit code could unadvise and release any existing objects, rather than hoping that LuaCOM or the script did so. (This also means it would work even for "other" languages, where right now.. its not certain that any simpler solution would work for "any" language.) However, it might grow to a few hundred lines of code, instead of 30 or so. lol Its also slightly less trivial to design. To impliment, probably trivial once you have the solution. But coming up with that solution...

Problem is, when I asked about doing that, having suspected that this might be a problem, I got the message board equivalent of a blank stare, which would seem to either imply we are both missing something absurdly obvious, or they just don't understand why this is not the same sort of environment they are working with and different rules apply to it. :(
Top
Posted by Nick Gammon   Australia  (23,121 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 28 Mar 2007 08:48 PM (UTC)
Message
Quote:

I got the message board equivalent of a blank stare ...


I get the impression with some of these things that the developers can make them work in a fairly controlled environment. For example, wxLua works (presumably) when running as a stand-alone application.

Also, my example of capturing a button click works, because you set up for it to work in advance.

If you have trawled through lots of Google searches, and not found anything relevant, it might be one of a number of things:


  • No-one has tried it

  • People who might try it realize it is impossible

  • People have tried it and failed, and given up

  • Someone has got it to work, but not seen the need to post how they went around doing it


You might find that the window of people wanting to do it is fairly small. Remember, when I wrote MUSHclient, Lua wasn't around (although MFC was). Now, Lua is around, but MFC is becoming less "pushed" by Microsoft. For example, ATL or .Net is being promoted instead.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #4 on Thu 29 Mar 2007 06:01 PM (UTC)
Message
Well. The real issue is probably 3 or 4 from that list. It certainly not "impossible". For example, while the information for LauCOM doesn't say why it might not always be a good idea to do so, it does imply that while you can impliment it *after* by loading it through the script, its intended to be integrated "prior", so its actually part of the automation of the application. ATL is almost as old as MFC. Its main purpose was to get around some limitations, but not directly supplant MFC. You can, as the page I mentioned shows, make some fairly minor changes to support (a) late bound object, using only a few lines of code and incorporating only a few extra headers. Note: .NET is intended to replace *everything* that came before it, more or less.

The real problem imho is the old, "We already solved this problem years ago and its locked up in some proprietary license." Nearly every application uses some sort of late bound function. IE, as one example, **requires** it to even work at all. And I have read stuff that fairly clearly indicates that at one point it was writen in MFC too. MFC itself even, as of 4.0 includes functions to redirect messages to a different part of the application, instead of handling it in the main loop, *specifically* because it was nearly impossible without that to do some things. This was before ATL became available.

In any case. This is, I suspect, one of those damn things, like so many I have seen in the past, that involves a case of, "If you don't know how to do it, we will sell you something for $500 that will do it, otherwise, good luck figuring it out!" And I will bet that if I specifically looked for a proprietary library or extension that supported it, I would find one. Hobbyists don't worry about this sort of thing much, professionals make a mint off of 100-200 lines of code they figure out, which is the heart of how their tricks work, and 500,000 lines of code that anyone with basic skills and some imagination could have written. And because its such a key and specific solution, they *can't* tell you how to do it.

Point of fact, I did get a response a few years back on the subject from someone that said, "Yeah, my company had the same problem and solved it, *but* I can't tell you what our solution was." Not real helpful, even if it did encourage me to keep looking.

And frankly, google searches are often completely useless if you don't know what to look for. I have done multiple searches on the subject and never once got the page on mixing ATL into MFC *until* I went looking for message redirection. If you look in the wrong places, you won't find what you are looking for anyway. I have almost "never" found anything from google on how to do something that I have **seen** done all the time in applications. Just look at raytracing. 90% of the pages for that either talk about differences in methods, OpenGL and DirectX or specific solutions to specific problems. Try to find something that explains the "basics" of how to actually build one... Not so easy (try damn near impossible).
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #5 on Thu 29 Mar 2007 07:03 PM (UTC)
Message
Given how much trouble you have had looking for this over however many years it's been I'm not surprised that those who find "it" (whatever "it" really is anyhow -- this is starting to feel like a Quest for the Holy Grail) tend to keep it to themselves or sell it for a profit. It's a shame for people like you who want it and aren't finding it independently, though. But, it does make some kind of sense, I suppose.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #6 on Fri 30 Mar 2007 08:45 PM (UTC)
Message
Yeah. Its a major pain in the rear is what it is. And in our case we are dealing with one more level of complexity. Think about IE. When you late bind an object in it, it works like this:

1. Create instance of browser window.
2. Load script.
3. Create objects.
4. Link objects to script.

Its a 1:1:1 system. With us we have:

1. Load client.
2. Load *scripts*.
3. Create objects (right now using the script, which IE doesn't do).
4. Try to link 1:N:N, where N is an unknown number of engines and an unknown number of objects.

Sane design would imply, and it might be best to do it this way, creating an object you can instance that exists parallel to "each" script which contains the objects, their references and what to call on their events. But it still means redirecting messages "to" those objects correctly.

Its like knowing, in principle, how anything works, but lacking the specific skills to forge, mill, mold, carve or code the key bits needed to fit all the bits you are completely familiar with into a usable whole. I've got two ends of a wire here and a two inch gap between them, with nothing I can bridge the gap with. Its bloody frustrating. Even more so because the morons (sorry, experts) at Microsoft all *love* to use the name "patron" for ****every**** example application they ever code in one of their blasted books. Even if I could be sure that they had an example in one of them for doing this, which I am not sure of anymore, it wouldn't matter, because how the hell do you google for a program called "patron", if their are 2-3 of the same named applications out for *every* book they ever published on their system, and the only relevant search terms (which I don't remember) only give you the original page on their site, which doesn't have *any* links to the code itself?

Its like someone telling you that they know the location of the lost city of atlantis and have GPS coordinates for it, but.. every single copy of the book has a huge smudge over the only mention of what those are, and the original manuscript was lost in some horrible printing accident at the publishers. Just makes you want to cry.. or *SCREAM* lol
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

20,092 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home