>  From: Robin Dunn [mailto:robin@[...].com]
>  >
>  > I've done it more than you (at least once a day since we've had a shell)
>  and
>  > I've brought it up with Robin and Neil on numerous occasions and so has
>  > Patrick since it also impacts the shell or anything else using
>  wxSTC. I'll
>  > let Robin respond once again to the list for the record.
> 
>  My understanding is that the clipboard funtionality in wxWindows uses the
>  OLE clipboard APIs on Windows and emulates that model on the other
>  platforms.  Basically it does not actually put the data in the clipboard
>  when a cut or copy happens, but just meta data about the data (type, size,
>  etc.)  When another app does a paste, the app with the data then
>  copies the
>  data directly to the other app.  If the app with the data
>  terminates before
>  the paste then there is effectivly no data in the clipbard any longer.
> 
>  wxWindows can be built to use the old win32 clipboard APIs instead of the
>  OLE ones, but I think we'll loose more functionality than we gain.

I just tried a copy/quit/paste with the doodle sample which uses
wxTheClipboard and the contents of the clipboard are lost at close there as
well.

This doesn't explain why the clipboard is not destroyed when copying text
from a wxTextCtrl, regardless of the style flags used. Something is
different between how the clipboard is handled with wxSTC and wxTextCtrl for
Cut and Copy. Maybe the wxTextCtrl Cut and Copy methods are bound
differently to the underlying native control? Does wxWindows go through some
clipboatd cleanup on exit that would show what is going on?

I'm still looking for an example of a Windows app where the clipboard data
disappears at exit and so far I'm not finding anything. Maybe most Windows
apps use the OLE clipboard APIS too, but before they shut down, they change
the clipboard so it persists? That might explain why the user is asked
whether they want to keep large clipboards or discard them? Keeping the
clipboard around with an option to discard large clipboards is the behavior
we want (the user friendly behavior), so the question is how to implement
it? I think it should be automatic, but since it couldn't be part of
wxWindows/wxPython until at least 2.3.3pre6 and I want it for 2.3.2.1, I
need to know how to do the transformation.

Maybe as Neil suggests we would have to use the win32all APIs; that won't
help on the Mac? If it is something that wxWindows isn't going to do and
would have to be done in Python anyway, then maybe like your wxPython IE
wrapper, wxPython could just have an extra module to handle the clipboard in
the user friendly way and both Windows and Mac could be handled properly.
Should the clipboard persist under GTK too or do apps not do that on
Linux/GTK?

Maybe we should move this discussion to wx-dev. If so, we can start by
forwarding this to wx-dev.

ka



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and much much more.
http://thinkgeek.com/sf
_______________________________________________
Pythoncard-users mailing list
Pythoncard-users@[...].net
https://lists.sourceforge.net/lists/listinfo/pythoncard-users