ActiveX and COM

Every reference for COM I have found (or own) either assumes you are using it as an embedded control in HTML or that you are calling it from inside a program. Having looked over the examples on here they are not very helpful. Basically there is no reference specifying A) where or how some controls can or will appear when used in mushclient or B) how to translate from the more common calls used on the web to what you need under mushclient (especially for me in vbscript).

So heres an example direct from the Plugin and ActiveX companion for IE I have:

This is 'probably' the most likely way anyone will see a COM control used, since 90% of the dang things are used on the web. :p So... Here's the question. How does the more common form used in html docs translate to calls in sripting, can/do some controls even work with mushclient and where exactly do they end up?

If it won't work, then does anyone know of a COM wrapper that will let you stick the components in another window? And doing a COM call to IE doesn't count, since that is like borrowing a tank from the military because you need something on which to test your new bumper sticker. You end up using 100 times the system resources you 'need' for virtually no result. :p

Ok.. I think looking over some things I know how 'most' of it works. My problem is the 'registration' part where you assign a name to the CLSID. Maybe the reference to this is just in a really obscure place, but the only example I can find in the forums refers to ODBC and doesn't use such registration (or the database is registered already outside the client). In either case it doesn't deal with how to properly access one that need to be registered in the script to work properly. :p We need to start puting tutorials for this sort of thing on here. lol A lot of stuff people are doing is just too complicated to keep reposting examples on the forums, especially if you can't seem to find the correct post. ;)

You want to find an existing COM object by name? Try Office Assistant sniplet which demonstrates that.

I agree the whole COM thing could be better explained - however I only partially understand it myself. :)

>You want to find an existing COM object by name?

Umm.. No. I don't think so anyway... In HTML you basically do the following:

1. Provide a unique name.
2. Assign that name to the CLSID of the object.
3. Call createobject to make an instance of it.

You don't have to do step 2 in a compiler because that is handled by the component editor, though it probably has it stored someplace within the source files. ODBC you can get by with not doing step 2 because the database is already the object (or something like that) so creating an instance doesn't require telling windows what CLSID you are trying to access. For most controls and other COM objects it seems you have to have this data. This is confusing. Normally using an activex control of the like from vbscript you have to provide something like the example I gave before you can do anything, but not being an html client this function isn't there. :p Maybe you can avoid it when using full programs, but I just don't get it and, as I said, all the examples available assume either HTML or full compiled programs. :p

This is one major reason I haven't tried doing some of the things I have been considering. It is all well and good to support COM, but only if everyone has a clue how it works. lol

What are you trying to do then?

• Connect to an existing COM object?
• Make a new COM object?
• Something else?

Hmm. Ok. Here is the thing...

Say I want to do the following in a script>
1. Make a reference to a new Richtext control.
2. Show the control.
3. Feed lines from say Tells into it so that you can keep track of them in a seperate window.

In true VB you would basically just add a reference to the control and drag-drop it into the form you made, then the compiler adds the needed headers and other references needed to let it work. All you do it tell it

Richtextbox1.Size = blah

or whatever to change its parameters. The Visual Basic software automatically handles the task of figuring out where this stuff is.

In an HTML doc you provide a name, then assign the CLSID for the control you want to that name. Then in vbscript you 'create' an instance of this control before assigning things to it.

Now in Mushclient you do???? The only examples available seem to imply two things. That A) mushclient somehow finds the correct control by name and B) automatically creates an instance of it (things that shouldn't technically be possible based on how HTML or full Visual Basic do things). This is what I don't get. It also causes a problem for controls that are not already registered, since mushclient can't 'find' something even the OS doesn't know exists, yet COM is supposed to support this through dynamic registration.

I just don't get how mushclient is doing things or how you can use a user created control or program that isn't already known to the system. Based on what I understand (and I admit I am only starting with this) even the examples given really shouldn't work the way they do. I seem to have missed something somewhere...

MUSHclient isn't exactly VB. I don't see how you are going to put a control on the screen (in MUSHclient) in the first place, let alone do things with it.

There are examples around of people who have done stand-alone COM objects (one recent one was a mapper).

In your case you might use VB (or C++) to write a little text displaying app, and then use the CreateObject to get a reference to it (ie. create one) and then feed lines into it.

Yeah. I realize it isn't VB or a browser, but that puts it into a sort of limbo where the rules are a little vague. I kind of figured that there might be some need to make a sort of wrapper to put the objects into, but there really isn't any such thing. As for the mapper and ODBC the situation is a bit different, these are more properly COM servers and the rules for them are a bit different that for other COM objects. I still don't entirely understand how or why it works though, since you are still creating a 'stub' to talk to the server and such stubs shouldn't be anymore accessable through a name than a control would be. But it does work so...

I just wish I had a good explaination of how the pieces fit together for mushclient and why. I don't think there are a lot of programs around that exist in the sort of in-between world that mushclient does and that makes figuring things out a bit interesting. lol

I heard a good explanation recently, that COM is to object files (ie. executable code) what "include" directives are to source files.

Thus, you are basically using COM (the O stands for Object) to include (use) pieces of object in your own code.

In the case of MUSHclient the COM interfaces were really provided to allow scripts to get the program to do something for them, so they are really "hooks" into internal MUSHclient routines, with a wrapper being the way arguments are processed (ie. as COM-supported argument types).

I suppose you could call MUSHclient a COM server because it provides services (eg. world.send) to a client (eg. the script called by a trigger).

Been nosing around a bit... Apparently IE is a ActiveX Document Container. There is only three programs that function this way: Binder (Was part of Windows 3.1, but not part of IE), IE and some program for windows called Finder (probably borrowed that name from Macs) that you can't get anymore. However, it looks like Outlook, Word and others also support this functionality... Grrr... I have yet to find either a decent example of how to impliment such a thing or even how they work. :P But basically you can have an ActiveX container, but that needs to be hosted on a Document Container or something of the sort according to what I have read.

About the only thing useful I did find was some rather vague references in a book I have about using IEs core COM dll to support such a container, but only for building a custom browser interface. Needless to say I am disappointed, since such a container would allow virtually any object to be dropped into it for which a control existed. Which is exactly what I want.

Oh, well, just gotta keep looking I guess.