COMet

COM Explorer for Tcl

Version 1.0, December 8, 2004

COMet is a COM exploration tool for COM interfaces in Windows. With COMet, you can instantiate COM objects, examine Collections and Properties, invoke Methods, and examine ENUMs in associated TypeLibs. Any Collection entry, or Property / Method result that is another COM object, can be instantiated and examined further. If a TypeLib for any object can be determined via Registry information, that library will be loaded and ENUM constants displayed. Other TypeLibs can be loaded manually. A log of COMet actions is maintained, and can be written to a file for further development.

COMet was written by TP because of sadly lacking and confusing COM documentation for a Windows project on which he worked. COMet is distributed under the Tcl BSD-style license.

COMet is available as a StarKit from the StarKit archive: https://www.tcl-lang.org/starkits

A TclKit for Windows is required, find one at http://www.equi4.com/pub/tk/

COMet is known to work with 8.4.9/tclkit-win32.exe.gz and 8.4.9/tclkit-win32.upx.exe TclKits from the TclKit distribution. Simply run the Tclkit executable with comet.kit as an argument, i.e.,

• tclkit comet.kit

A StarPack of COMet is be available at the same StarKit archive, using the upx Windows TclKit. Look for comet.exe.

COMet relies on tcom for COM interaction, and uses BWidget for highlevel widgets. The COMet StarKit contains tcom version 3.9 and BWidget 1.7.0, so you don't need to worry about installing these packages.

Bugs / Problems / Caveats

TP Dec 8, 2004 ver 1.0

• The list of COM objects is determined by looking at objects that have a Programmable or LocalServer registry key. I have no idea if this is correct, but it works for me :-)
• COM objects are displayed in a BWidget Tree. It seems to be rather slow on opening nodes. I don't know if the representation of "Objects By Name" vs. "Objects by Type" is really important or not for finding the object you want.
• Methods cannot be invoked that require arrays arguments. Only scalars are permitted at this time.
• Many COM objects don't seem to have Registry references to their associated TypeLibs. You'll have to find and load TypeLibs manually.

male Dec 10, 2004

• The UI is not scalable and the right vertical dived array is not scalable to (like in paned windows)
• methods with optional arguments are not callable, if no argument data is given in the method call dialog

Stefan Vogel Jan 19, 2005

Wow! This is veeery coool. That kind of application I've needed just two months ago! Thanks a lot for this.

Snichols Jan 21, 2005

I gave the starpack a try and this application is very helpful. I never knew my Windows OS had so many registed COM servers. I really like how you can interact with them too. I'll think I pass this along to coworkers who need to do any COM programming to existing servers.

SV (2006-06-01) New, slightly modified version.

Changes:

• The list of COM objects is expanded to include objects which have InprocServ32 registry key.
• Fixed problem with OUT argument for methods, such is in 'Execute' method of ADODB.Connection
• Popup of console when user press '?' in main window. (I find it very helpful)

Kit build: WinXp Home

Exe build: UPX packed, WinXp Home, TclKit/Tk 8.4.4 (rest of packages is the same like in original)

Downloads at http://www.datagram.hr/download

Awesome application, thanks TP! It looks now that wandering of mine in MS ADO world will end happily.

JMN I just downloaded the 2006-06-01 version from http://www.datagram.hr/download .. I think 'findTypeLibs' needs to be more robust.. I get a crash on the line:

 registry get $key\\$win32key ""

The error is:

 unable to get value "" from key "HKEY_CLASSES_ROOT\TypeLib\{860CC660-1C2B-11D0-B1B1-44453540000}\4.2\0\win32": the system cannot find the file specified.

Looking in regedit.. it seems the Default value for that key isn't set. I don't know enough about this app or the registry to know what the proper fix is. I guess I'll just try wrapping that call in a 'catch' and see how it goes.

escargo 18 Oct 2007 - I just downloaded the comet.exe from http://www.datagram.hr/download and I was able to start the exe normally. However, when I tried to create a Word.Application object, I got this message.

 bad window path name ".m.frame.3.pm.fWord"
 bad window path name ".m.frame.3.pm.fWord"
     while executing
 "frame $path.f$page -relief flat  -background [Widget::cget $path -background] -borderwidth 0"
     (procedure "PagesManager::add" line 11)
     invoked from within
 "PagesManager::add .m.frame.3.pm Word.App"
     ("eval" body line 1)
     invoked from within
 "eval [linsert $args 0 PagesManager::$cmd .m.frame.3.pm]"
     (procedure ".m.frame.3.pm" line 1)
     invoked from within
 "$wid(pager) add $objName"
     (procedure "newObjDialog" line 37)
     invoked from within
 "newObjDialog $w $node existing"
     (procedure "newComObjDialog" line 4)
     invoked from within
 "newComObjDialog .m.frame.1.sw.t"
     ("uplevel" body line 1)
     invoked from within
 "uplevel \#0 $cmd"
     (procedure "Button::_release" line 19)
     invoked from within
 "Button::_release .m.frame.1b"
     (command bound to event)

SV (2007-10-18) escargo if you asking me to solve this error I must disappoint you, unfortunately. I don't have any spare time to debug it, maybe in some distant future. To be frankly I even don't remember half of that COM stuff any more. However I do remember that it is a well written tool and you should be able to fix it. Happy coding and good luck!

escargo 19 Oct 2007 - I'm more reporting the bug. I'm not sure the bug is in the COMet code itself; it looks like it might be code that it calls. I'm not sure that I understand the fundamental nature of the problem yet.