Gammon Forum : MUSHclient : General : External Apps Controlling Mushclient (COM)

Entire forum ➜ MUSHclient ➜ General ➜ External Apps Controlling Mushclient (COM)

External Apps Controlling Mushclient (COM)

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

Posted by

Onoitsu2 USA (248 posts) Bio

Date

Tue 31 Oct 2006 07:14 AM (UTC)

Message

As most people know there is a plugin called "Super Health Bar" and it is an implementation of COM into a VB Application. I have been programming using a language called AutoIt, and have managed to create a child MDI window, for use in sending SW's, the window iterlf dynamically sizes itself in the lower right corner of the MDIClient1 control (The grey section behind world files, if maximized), and it reads its SW's from a txt file, that is located in the same directory as the executable itself, which can be anywhere. It also has a list of ALL open worlds and you can choose which one you wish to send the SW to. Once an area is selected from the pulldown list, it populates a text box with the SW for easy editing before sending to the editbox within the desired world. There is a clear button if you wish to clear the box, and then the send button, which also responds to ENTER if the new window is active.

It is NOT implemented as as Plugin, and is ENTIRELY independent of MUSHclient. Run it when you want, don't when you don't need it.

I have been able to try to access MUSHclient's COM interface using AutoIt, and have been only successful in creating a NEW MUSHclient.World object, and can send ANY command it will respond to, BUT I cannot seem to attach to a pre existing world file, and I believe it to be the implementation of COM in Mushclient itself, the IDispatch section of the COM interface is restricted, as well as MANY other sections, I found this from using the OLE/COM Object viewer that Microsoft distributes. I think that some of the actual programmers here would agree, that if one could create a new instance of a control, that you should be able to attach to a pre-existing one with the same ease.

I do not know if what I am asking is possible, but I think that MUSHclient would be extremely well off if it allowed several other COM interfaces to be exposed, and was less restrictive in that aspect.

If you would like to try out my program I have created e-mail me at Onoitsu2@yahoo.com, and I can attach it in a reply. And Nick I have already sent it to you, if you check your e-mail address you sent me a message from you should see it there. I can and will also send the source file I used to create it, it is not the cleanest, but it works quite well for what it does do :) I plan on implementing a hotkey that makes it active, and deactivates it, so you can still have your world file maximized.

Please Nick, and ANY other programmers on this forum, with your 2 cents on this idea, because it could make the plugins that are distributed with mushclient much more powerful, as AutoIt, or any language that can implement COM, could allow for many amazing things to be done, such things as temporary triggers, or aliases, auto healers that have a full GUI even. And for Linux users using wine, I do not know if you can implement COM yet, or some form there of, but 90% of Apps made using AutoIt are usable in wine, I have a weather map by region displayer (USA only) that functions with only a 1 line change to the code, which is removing the internet check, which is pinging google.com and seeing if the ping is greater than 0, which is a fail.

I know that my thoughs here are sporadic, and misaligned, and I am sorry, but that is how my though process works, and I have done many a great thing because of it, the program of which I speak is one of them :)

Laterzzz,
Onoitsu2

Top

Posted by Nick Gammon Australia (23,046 posts) Bio Forum Administrator

Date Reply #1 on Tue 31 Oct 2006 08:28 PM (UTC)

Message

I know what you mean, and can explain what is going on a bit.

When you try to access MUSHclient from another COM application, the first thing you do is create a COM object, eg.



Set w = CreateObject ("MUSHclient.World")

The problem here is the object is created, thus you get a new, empty world.

One work-around I am looking at, without huge success at the moment, is allowing you to get to the application itself, eg.



Set a = CreateObject ("MUSHclient.Application")

However again I think you get a new copy of the application, not an existing one.

What you can do once you get the world is to use GetWorld to find another world, eg. inside MUSHclient (in VBscript):



Set w = GetWorld ("Realms of Despair")

w.Note "Hi there"

Your problem here is to get that initial world, so you can find other ones.

So far the only solution I have found is to turn the paradigm around. Get MUSHclient to instantiate your application, not the other way around.

Thus, an existing world could do CreateObject to get your health bar (or whatever) and then it can send the world object to the external program. Now, armed with the world COM object, the external program can "call back" into MUSHclient and to Note and so on.

Search the forum for CreateObject, there has been some discussion about this before.

- Nick Gammon

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

Top

Posted by

Onoitsu2 USA (248 posts) Bio

Date

Reply #2 on Wed 01 Nov 2006 07:52 AM (UTC)

Message

I already have a working version of the Super Health Bar plugin, that supports color changing percentage bars for HP, MN, and MV, shows the gold, and tnl (if TNL < 100 is cyan) and then if in battle shows the Enemy Life % in a large box. Also supports whimpy, and auto heal/mana options all customizable from a separate options dialog it displays.

The question is not of implementing a new instance of something, when an object already exists in COM, it is added to the listing of existing objects in memory, only if it has a certain interface within its code,i believe that it is called Dispatch, and only if it has that interface does it report itself into that listing.

In the language called AutoIt, there is a command called ObjGet ( "filename" [, "classname"] ) that gets an object reference to an existing object stored in a file, or process, and the classname is optional if a filename is used instead of a PID.

I have tried to use the HWND reference to the world window for such a function call, and have been unsuccessful thus far. I also have tried to print, display, etc. in any way possible a reference to the world from within mushclient, so that I can, even if it is a one time use, be able to retype that reference into my program, to use.

I believe with a few added functions, or the ability of using MUSHclient.Application as an object, then from there doing a call to the world list, and that function returns either the full array of worlds and names, or does an string in string match on the world names and returns the first match, so that you will have a reference to the world itself.

I hope that I have used the correct terminology, and logical layout of said functions. I know HOW COM works, but have seen VERY few documents that explain how to USE it in personal apps for anything except for the MicroStupid Applications.

Thanks,
Onoitsu2

Top

Posted by

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

Date

Reply #3 on Wed 01 Nov 2006 07:16 PM (UTC)

Message

Quote:

... there is a command called ObjGet ( "filename" [, "classname"] ) that gets an object reference to an existing object stored in a file, or process ...

If this indeed works, the world object (ie. a particular world) is called MUSHclient.World.

I never implemented MUSHclient.Application, although I attempted to recently after reading your post. Unfortunately, retrofitting something like that into something that a Microsoft "wizard" generated originally (years ago) is quite a frustrating exercise.

However I still think that even if I got it to work, you would end up with a new copy of MUSHclient, not a link to an existing one.

I think my suggestion of getting MUSHclient to create your external control, and then call back into itself, will work better. I think Poromenos got something like that to work a while back.

- Nick Gammon

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

Top

Posted by

Onoitsu2 USA (248 posts) Bio

Date

Reply #4 on Wed 01 Nov 2006 08:00 PM (UTC)

Message

Well I am trying to make an "addon" application, that can show maps and such item INSIDE of the mushclient MDIClient window, so that there is no need for all of this txt maps and other work arounds that have been used.

Also Nick have you checked your e-mail for something from my Onoitsu2@yahoo.com address? I sent you an example App that adds a Child window to the MDI, for use in Speedwalks, and it reads from a txt file, where sections start as
[Area Name]
SW="PUT SW HERE"

[Area Name2]
SW="PUT SW2 HERE"

and so on, and it populates the listbox from the section headings, and when you choose one from the pulldown it reads in the SW setting within that heading.

So it can, with a little alteration, work on ANY mud just by supplying your own SW_List.txt file, which if it does not exist in the location the Program I made is located (is dynamic can be on desktop, c:\, anywhere in fact) it will be created and populated with basic Aardwolf SW's.

Once you run this app Nick, you will see why I wish to do things in such a way as an external app, WITHOUT the user having to use a plugin to call it. I mean there is nothing wrong with having to install a plugin, for such a use as the Super Health Bar plugin, but in my requirement it would be a stub of a plugin file, and not even that would be necessary as it COULD control multiple open world files.

The example I mailed you is NOT using COM, it is using window and control HWND's and controlling the controls themselves, with NO access to reading of variables, nor any functions in mushclient.

My reason for wanting to be able to do the ObjGet is so that people, using AutoIt can create their own addon Applications, as it is a VERY powerful scripting language, so powerful in fact that you can create near full applications using it, I say near full, as it itself CANNOT be controlled via COM, but can control other programs. And the language is VERY simple, the source for the program I sent you is only 7.21 KB (7,392 bytes) and the compiled and UPX'd maximum compressed AND using a custom Icon I added is 186 KB (190,525 bytes), and that is including the 9.44 KB (9,670 bytes) SW_List.txt default when not existing.

I wish to somewhat push the limits of what clients in general do, and allow the creation of powerful interfaces, controls, and features. There is a client that shows a visual "compass" based upon the room exits, and that would be a nice "widget" to create for MUSHclient users.

I hope you see where I am going with this here Nick, and I do realize I am rather long-winded about the topic, but when I get an idea stuck in my head it drives me nutz until I can at least in part get the ball rolling toward its completion. The program I sent you was made in a matter of hours, because I sat in front of my computer unmoving, undestracted for about 6 hours, from start to debugging, to finish.

Thanks for all your replies, and this great client.
Onoitsu2

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.

14,644 views.

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

Go to topic: Search the forum

top