Clipboard selection on MSW from read-only wxTextCtrls

Forgive me if this has already been discussed, but the link for
the archive search on the wxPython page is not working, so I couldn't
scan for prior discussion of this topic... (http://lists.wxwindows.org
seems to be dead at the moment...)

For a long time, I've been annoyed that I can't use Ctrl-C in the
wxPython demo's demo code tab to copy snippets into the clipboard
on my windows desktop. (Being able to do so would be *verry*
convenient.)

So, I finally decided to try to figure out why not...

I looked at the drag&drop demo, which illustrates use of the clipboard,
and I managed to copy and then paste from and/or to the text window on
the left, using Ctrl-C and Ctrl-V, respectively. I modified my copy of
the drag&drop demo to log when its copy and paste functions were executed,
and they never did in response to these key events, even though the
windows clipboard was clearly being manipulated and cutting and pasting
was going on.

(Aside: I also noted two flaws in the drag&drop demo:
  1) The demo doesn't pay any attention to the selection within the text
     window; it simply copies the whole contents of the control into the
     clipboard.
  2) The demo doesn't pay attention to the cursor position when pasting
     either, instead replacing the entire contents of the text window.)

The only difference I can see between the wxTextCtrl in the main demo's
"demo code" tab and the one in the clipboard demo is that the former is
marked as wxTE_READONLY. So, my conclusion is that the bindings for
Ctrl-X, Ctrl-C and Ctrl-V on a wxTextCtrl are implicitly set up at
creation (at least under windows)... unless the wxTextCtrl is marked as
wxTE_READONLY.

If true, this seems like a bad decision in the underlying implementation;
if it's going to go through all the trouble of setting up the Ctrl-X,
Ctrl-C and Ctrl-V handlers on a normal wxTextCtrl on windows, why not
install the Ctrl-C bindings for readonly ones? (This seems to me like a
baby/bathwater problem...)

I suppose I could write and submit a trivial "clipboard-aware" read-
only wxTextCtrl derivative class, adding an OnChar() handler that, on
Ctrl-C, reads the current selection and replaces the clipboard contents,
and otherwise just passes the event to the regular handler. But this
would make it work right only for wxPython, the key binding may not be
the right one for other platforms, and this doesn't seem to me like it's
the right solution, as one would expect a read-only wxTextCtrl to allow
copy on all platforms anyway...

Should this be considered a wxWindows bug? Is there something I'm
missing?

/Will Sadkin
Parlance Corporation
wsadkin@nameconnector.com

Will Sadkin wrote:

The only difference I can see between the wxTextCtrl in the main demo's "demo code" tab and the one in the clipboard demo is that the former is marked as wxTE_READONLY. So, my conclusion is that the bindings for Ctrl-X, Ctrl-C and Ctrl-V on a wxTextCtrl are implicitly set up at creation (at least under windows)... unless the wxTextCtrl is marked as wxTE_READONLY.

If true, this seems like a bad decision in the underlying implementation; if it's going to go through all the trouble of setting up the Ctrl-X, Ctrl-C and Ctrl-V handlers on a normal wxTextCtrl on windows, why not install the Ctrl-C bindings for readonly ones? (This seems to me like a baby/bathwater problem...)

Talk to microsoft. wxWindows doesn't do anything at all for those key events in the wxTextCtrl. It's all handled by the native control. The issue is compounded by the fact that the native control behaves differently on different versions of the MS CommonControls DLL. For example on my system the Copy works fine in a read-only control.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hmm, this is interesting. I'm pretty sure that on Win2K, copy (Ctrl+C) used
to work for a single line read-only wxTextCtrl, but it doesn't seem to work
now. However, copy does work for a read-only, multi-line wxTextCtrl using
the wx.wxTE_RICH2 style. It might work for single line wxTextCtrls too if
you used the wxTE_RICH2 style, but I don't plan on making that switch for
PythonCard.

ka

···

-----Original Message-----
From: Robin Dunn

Will Sadkin wrote:
> The only difference I can see between the wxTextCtrl in the main demo's
> "demo code" tab and the one in the clipboard demo is that the former is
> marked as wxTE_READONLY. So, my conclusion is that the bindings for
> Ctrl-X, Ctrl-C and Ctrl-V on a wxTextCtrl are implicitly set up at
> creation (at least under windows)... unless the wxTextCtrl is marked as
> wxTE_READONLY.
>
> If true, this seems like a bad decision in the underlying
implementation;
> if it's going to go through all the trouble of setting up the Ctrl-X,
> Ctrl-C and Ctrl-V handlers on a normal wxTextCtrl on windows, why not
> install the Ctrl-C bindings for readonly ones? (This seems to
me like a
> baby/bathwater problem...)

Talk to microsoft. wxWindows doesn't do anything at all for those key
events in the wxTextCtrl. It's all handled by the native control. The
issue is compounded by the fact that the native control behaves
differently on different versions of the MS CommonControls DLL. For
example on my system the Copy works fine in a read-only control.