All the raging about COM in the past...

Posted by Onoitsu2 on Mon 04 Feb 2008 09:04 AM — 7 posts, 36,589 views.

USA #0
I have been looking over the source, and Nick has had the answer to the COM situation for a while. I located this URL in the source, and have looked it over, as well as looked at a few other things for use in VB apps. Things like getting functions and methods to show up in the "Global" section of the actual library itself, and not in the world section (look in object browser after setting a reference to the mushclient.tlb file)

So far I've modified the odl file properly (loads different from the URL below, uses 2 new GUID's, one for IMushclientApp, another for MUSHclientApp (coclass of IMUSHclientApp), and adding the option 'appobject' to the UUID section for the MUSHclientApp, Anything added here will be located globally now), but have had issues with adding the other IDispatch methods, or more like having trouble not getting at least 40+ errors.

The next thing that would have to be done is creating an altered version of the GetWorld function that DOES NOT use the CMUSHclientDoc methods, so it communicates with the application itself, not the documents (open world(s))

If someone could clarify a few things with this, I might just be able to get this working so that you can directly query the MushclientApp interface for the COM reference to the document (world) based upon the name you provide. Which would allow separate programs to interact with mushclient via the world name, and have full access to its scripting functions. i.e. Clickable buttons, gauges that can access world variables, the ability to toggle triggers, aliases, timers, whatever via another application that can access COM objects.

Take a look at:
http://www.codeproject.com/com/mfc_autom.asp

-Onoitsu2
Amended on Mon 04 Feb 2008 09:05 AM by Onoitsu2
Netherlands #1
Nice work.. although I don't really need it. I'm writing my interface so it will switch along with the active world so each interface will need its own specific hook into a specific world.. which I already found a way of getting.

Anyhow, nice work. I'll take a look at your link some time when I'm more awake. *waggle*
USA #2
Well I did not DO anything, Nick already had that URL in the source, as well as some of the things needed, but commented out.

I have been tinkering with it and have gotten a few steps into getting it to work, but am just stuck as far as getting it down from the 40+ errors.

-Onoitsu2
USA #3
Not to be a pain, but I wasn't aware that this was a huge issue.. Mind you, I don't remember if Mushclient has events it fires or not, but if it does, then you are not fixing anything, since 90% of the script environments you are likely to find have the "same" problem as Mushclient. Unlike IE, they don't support objects in a way that allows event handling, unless you bind the object during compile, which is the same thing you need to do now using the .tlb file. You don't gain anything that way. If you only want access to the functions, then yeah, its great, but your opening a one way communication channel, where your "host" can talk to the client, and make direct requests, but where your host can't *listen* to the client, since it can't hear it (same problem we now have hosting controls/objects "in" Mushclient which we don't write ourselves, so can't force to talk through functions).

But, heck, this *might* partly solve that issue too, since it stems from the interesting mess of not having complete COM support in the client, and anything that gets closer to that *might* help fix the other.
Netherlands #4
My work-in-progress application has semi-solved this issue. I can call world functions from it, and I can send data back to it as well. I'm not really happy with the sparse way some of it is handled, but it is possible which is what really matters.
Australia Forum Administrator #5
Quote:

I have been looking over the source, and Nick has had the answer to the COM situation for a while.


I'll be pleased if you can make it work, and you can probably find commented-out parts that didn't work for me. I found I either got errors, or it simply didn't work.

I eventually lost patience, but if you can make it work, well and good.
#6
I don't know your particular application, but if you can get the information/control you need from the existing MUSHclient API, the CallPluginAsync patch I posted a while ago provides a slightly less scary way than COM to call functions in MUSHclient. You pass it the world name, plugin name and function name as strings. It's like a super simple version of the COM STA model, only without the COM. And less COM can't be a bad thing right? :)

http://www.gammon.com.au/forum/?bbsubject_id=8334&page=1#47305