Gammon Forum : MUSHclient : General : All the raging about COM in the past...

Entire forum ➜ MUSHclient ➜ General ➜ All the raging about COM in the past...

All the raging about COM in the past...

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

Posted by

Onoitsu2 USA (248 posts) Bio

Date

Mon 04 Feb 2008 09:04 AM (UTC)

Amended on Mon 04 Feb 2008 09:05 AM (UTC) by Onoitsu2

Message

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

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #1 on Mon 04 Feb 2008 09:58 AM (UTC)

Message

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*

Top

Posted by

Onoitsu2 USA (248 posts) Bio

Date

Reply #2 on Mon 04 Feb 2008 10:44 AM (UTC)

Message

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

Top

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #3 on Mon 04 Feb 2008 04:47 PM (UTC)

Message

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.

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #4 on Mon 04 Feb 2008 05:36 PM (UTC)

Message

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.

Top

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Reply #5 on Mon 04 Feb 2008 08:25 PM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Pink Olifaunt (11 posts) Bio

Date

Reply #6 on Sun 17 Feb 2008 08:46 PM (UTC)

Message

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

http://pink.olifaunt.googlepages.com/home

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.

26,282 views.

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

Go to topic: Search the forum

top