This report is based on the OS/2 port, likely (and
reportedly) to behave the same in Windows. Unix too???
The current clipboard code is message based. When you
put something to clipboard, Tk claimes itself the owner
of clipboard. But it does not put there anything yet
(somebody thought that this is an optimization?!).
When another application requests clipboard contents,
the owner (Tk) is notified (via a message), and then it
fills the contents. However, if nobody asks, Tk won't
put anything when it exits.
On exit, the owner of the clipboard gets a message
requesting filling the clipboard. On OS/2 this is
WM_RENDERALL (sp?). Tk throws this message away; it
should not, and should process it as another message
requesting clipboard contents.
Jeff Hobbs writes at c.l.t.:
"...If you actually do paste the copied data from the
clipboard once, it will remain there after the app
exits. The one thing that is missing is that Tk
doesn't force the copy onto the
clipboard at app exit. The reason Tk is lazy in the
copy is to prevent large data sets being copied..."
My personal view is there should be both a "lazy"
method, to "prevent large data sets being copied", and
a "force" method, to make sure the new clipboard
content will be there after an exit. The programmer can
always check the size of the data currently stored in
the clipboard and choose between the "lazy" or "force"
methods on exit.