Gammon Forum : MUSHclient : General : COM redux...

Log on

Gammon Forum

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,786 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 (22,975 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,786 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 (22,975 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,786 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,786 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.

18,320 views.

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

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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