TIP: 150 Title: Implement the Tk send Command for Windows Author: Pat Thoyts Type: Project State: Deferred Vote: Done Tcl-Version: 8.5 Version: $Revision: 1.6 $ Keywords: tk, send Created: 25-Jul-2003 Post-History: ~ Abstract This TIP proposes to provide an implementation of the send mechanism for Tk under Windows. ~ Rationale The Tk send command is used to provide an X server based mechanism for transmitting information between Tk applications. This provides the basis for remote introspection (tkinspect) and remote control (tkcon). This subsystem has never been implemented under Windows although there are means to emulate this using Tcl's dde package or the comm library. By providing a win32 implementation we help to standardise the Tk command set across platforms and will make it simpler to use this feature from Perl/Tk and Python Tkinter. ~ Reference Implementation This implementation is based upon an integrated version of the winsend package currently at http://tclsoap.sf.net/winsend/. This uses the Windows Running Object Table to maintain interpreter registration information. This is a global system COM object that is provided as part of the Windows COM automation framework. Its purpose is to provide a single registry for maintaining references to active COM components. When ''tk appname'' is called a COM component is created which contains a reference to the Tcl interpreter. This is then registered with the Running Object Table with the registration name containing the Tk app-name. To find available interpreters we use the ''winfo interps'' command. This iterates over all the registered objects looking for Tk registered names and can then return a list of registered interpreters. The Tk ''send'' command is then provided as a COM method call. To perform a send, the client interpreter (or indeed any automation capable COM client) obtains the interpreter reference from the running object table and calls the ''Send'' method on this object, passing in the command as a string. For the synchronous version this is sufficient. The result is returned using the standard COM method calling and error information can be returned the same way. Support for the asynchronous send is currently underway but will be modelled closely on the X-based asynchronous send. There are some advantages in using COM over DDE for the transport mechanism. DDEML has a tendency to use broadcast window messages. If there are any toplevel windows that are not processing their message queues, then DDE gets hung. While a fix has been applied to the Tcl dde package, there remain problems. In contrast the COM-based system never broadcasts. We initiate a conversation with the Running Object Table first and then with the specific application requested. If this application fails to process its message queue then we will get stuck - but no other poorly behaved application can affect our communication. A second advantage is than non-Tcl automation capable clients can also call our method. This means that Windows Scripting code (vbscript or jscript) can make use of the send command. Finally, given a suitable DCOM environment it should also be possible to implement the -displayof feature via Distributed COM. However, I don't see much call for this - network sockets are a lot simpler to use than DCOM. ~ Copyright This document is placed in the public domain.