- tclkit comet.kit
Bugs / Problems / CaveatsTP 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.
- 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
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)
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.
