Send is a revelation. Many Tk (and even Tcl) programmers claim it as indispensable. Start by reading the distribution documentation mentioned above.

Can someone sketch up an example of how to use send - demonstrating some of the things one should be certain to consider when working with send?

Can different Tk bindings communicate through send? Yes--Perl/Tk, Tcl/Tk, and Tkinter are all happy sending messages to each other with built-in send. At some point, we need to present examples of this ... Steve Lidie devotes an entire chapter of his Perl/Tk book to send.

LV Back in the olden days, there was also an X Windows system library that allowed one to communicate between Xt based applications, with a Tcl interpreter, and Tk applications via send.

However, I don't know of any method for non-GUI applications to communicate via send to Tk applications, nor of a way for Java applications to communicate via send with Tk applications.

Start small with your send programming. Use a couple of simple Tk instances, to work out the security and application-name issues. Once those are properly settled, it's usually quick work to automate as much as you choose.

CAVEAT: The Tk send command depends on working with an X server and thus does not work normally on Windows or MacOS. Check out dde for Windows and Tcl's AppleScript support for Mac.

See also comm (a send look alike based on sockets which should work cross platform and cross machine), dde, and other methods listed in the Inventory of IPC methods.

PT writes on 29 March 2002:

I have released a preliminary version of a send for MS Windows systems that uses COM to do the work of registering interpreters and passing messages around. See http://tclsoap.sourceforge.net/winsend.html for more information and for the package. The source is in the CVS repository there (cvs -d:pserver:[email protected]:/cvsroot/tclsoap co winsend).

At the moment (Nov 2002) I'm not sure how successful the winsend package has been. However, there have been over 200 downloads so I imagine it's been of some use to someone :)

DKF: A version of this (based on the spec in TIP#150[L1 ]) is going to be in Tk 8.5a1 when that is released.

Pat Thoyts gave this example for a send substitute with DDE in the Tcl chatroom:

 # Emulate the 'send' command using the dde package if available. 
 if {[info command send] == {}} { 
    if {![catch {package require dde}]} { 
        dde servername TkInspect-[pid] 
        proc send {app args} { 
            eval dde eval [list $app] $args 
        } 
    } 
 } 

PT writes:

This is a suggestion for a generalisation of the send functionality. This is derived from the tkinspect send handling and should help a little with the use of send in a cross-platform application.

 # send.tcl - Copyright (C) 2002 Pat Thoyts <[email protected]>
 #
 # General send command
 #
 # This provides an abstraction of send, appname and interps that works for
 # all available send mechanisms. This is especially useful for Windows where
 # the usual Tk send is not available.
 #
 # We attempt to use the most efficient transport available. If the normal Tk
 # send command is present then this will be used. Otherwise we try winsend,
 # then dde for windows before defaulting to use comm.
 #
 # The interps command will try and build a list from all available transports.
 #
 # The appname command will try to apply the new name to all transports and
 # will read it from them all as well.
 #

 namespace eval send {
     variable version 1.0
     variable rcsid {$Id: 1055,v 1.23 2007-02-03 07:00:07 jcw Exp $}

     namespace export send interps appname
 }

 # Try using Tk send first, then look for a winsend interp,
 # then try dde and finally have a go at comm
 proc send::send {args} {
     array set opts [list displayof {} async 0]
     while {[string match -* [lindex $args 0]]} {
         switch -exact -- [lindex $args 0] {
             -displayof { set opts(displayof) [Pop args 1] }
             -async     { set opts(async) 1 }
             -- { Pop args ; break }
             default {
                 return -code error "bad option \"[lindex $args 0]\":\
                     should be -displayof, -async or --"
             }
         }
         Pop args
     }    
     set app [Pop args]

     if {[info command ::winfo] != {} 
         && [lsearch -exact [::winfo interps] $app] > -1} {
         set cmd ::send
         if {$opts(async) == 1} {append cmd " -async"}
         if {$opts(displayof) != {}} {append cmd " -displayof $opts(displayof)" }
         eval $cmd [list $app] $args
     } elseif {[info command ::winsend] != {}
               && [lsearch -exact [::winsend interps] $app] > -1} {
         eval ::winsend send [list $app] $args
     } elseif {[info command ::dde] != {}
               && [lsearch -exact [dde services TclEval {}] \
                       [list TclEval $app]] > -1} {
         eval ::dde eval [list $app] $args
     } elseif {[package provide comm] != {} 
               && [string is integer [lindex $app 0]]} {
         if {$opts(displayof) != {} && [llength $app] == 1} {
             lappend app $opts(displayof)
         }
         eval ::comm::comm send [list $app] $args
     } else {
         return -code error "bad interp: \"$app\" could not be found"
     }
 }

 proc send::interps {args} {
     array set opts [list displayof {}]
     while {[string match -* [lindex $args 0]]} {
         switch -exact -- [lindex $args 0] {
             -displayof { set opts(displayof) [Pop args 1] }
             --         { Pop args ; break }
             default {
                 return -code error "bad option \"[lindex $args 0]\":\
                     should be -displayof or --"
             }
         }
         Pop args
     }

     set interps {}
     if {[info command ::winfo] != {}} {
         set cmd "::winfo interps"
         if {$opts(displayof) != {}} {           
             append cmd " -displayof $opts(displayof)"
         }
         set interps [concat $interps [eval $cmd]]
     }
     if {[info command ::winsend] != {}} {
         set interps [concat $interps [::winsend interps]]
     }
     if {[info command ::dde] != {}} {
         set servers {}
         foreach server [::dde services TclEval {}] {
             lappend servers [lindex $server 1]
         }
         set interps [concat $interps $servers]
     }
     if {[package provide comm] != {}} {
         set interps [concat $interps [::comm::comm interps]]
     }
     return $interps
 }

 proc send::appname {{newname {}}} {
     set appname {}
     if {[info command ::tk] != {}} {
         set appname [eval ::tk appname $newname]
     }
     if {[info command ::winsend] != {}} {
         set appname [concat $appname [eval ::winsend appname $newname]]
     }
     if {[info command ::dde] != {}} {
         set appname [concat $appname [eval ::dde servername $newname]]
     }
     # comm? can set port num and local/global interface.
     return [lsort -unique $appname]
 }

 proc send::Pop {varname {nth 0}} {
     upvar $varname args
     set r [lindex $args $nth]
     set args [lreplace $args $nth $nth]
     return $r
 }

 package provide send $send::version

 # Local variables:
 #   mode: tcl
 #   indent-tabs-mode: nil
 # End:

LV Has anyone investigated what would be necessary for non-Tk applications to send info to Tk apps in the same manner as the Tk send? For instance, if I have a Java application or some other language without a Tk binding...

Well, one thing that could be done is to write a Tclblend wrapper for the Java code. Then write some code that talks to the Java code and then acts as a send manager.

PT 26Jun2003: There is an Xt based library - tclXtSend [L2 ] [L3 ] which permits non-Tk applications to use send. It may be out of date though.

LV Sometimes a Tk application dies and its interpreter is left registered with the window manager. When this happens, one can see things like this:

 $ wish 
 % send Display.tcl puts $args
 can't read "args": no such variable
 % send Display.tcl info vars
 no application named "Display.tcl"
 % winfo interps
 wish Driver.tcl pilotManager xfilewatch.tcl
 % send Driver.tcl puts abc
 target application died or uses a Tk version before 4.0
 % winfo interps
 wish Driver.tcl pilotManager xfilewatch.tcl

Has anyone a tip on how to clear out that interpreter name?

LV What are some techniques that a Tk application can use to discover to what applications it can send commands?

kostix (17-Sep-2007) notes that you must enter event loop to use send -async properly. I don't know Tk internals but it looks like the first call to send -async in a chain always succeeds but if a series of these commands is fired in a quick succession, second and following commands get queued and won't be dispatched unless the event loop is running. If it's not running each new send -async will "pop" the command entered that "queue" first while your current command will be added to the end.

LV So, does anyone have code demonstrating the starting of two or more tcl/tk threads and then the tk's sending information between one another? A simple illustration bit of code (that could be used to verify that send is working in one's environment) would be wonderful - an actually useful bit of code would be amazing.

apptalk - simple front end to the Tk send command

See also

• tk appname
• winfo interps
• Expect has a different meaning for send