Re: [lmi] Pasting between multiline edit controls

[Vadim Zeitlin]

On Thu, 08 Oct 2015 23:49:01 +0000 Greg Chicares <address@hidden> wrote:

GC> Pasting from one multiline edit control to another causes newlines to be
GC> translated to semicolons--because that's what pasting from the clipboard
GC> does in lmi--because we deliberately coded it that way--because end users
GC> wanted to paste from spreadsheet columns into input-sequence fields, but
GC> we didn't want to restrict it to such fields--because at that time we did
GC> not distinguish such (input-sequence) fields.

 I didn't realize this. I noticed the behaviour you describe too and even
found the reason for it in the code, but after seeing the comment about
intercepting this event for "all windows" I just assumed there must have
been a reason for it (e.g. that there were different kinds of windows for
which this replacement made sense) and didn't go further than that.

GC>   /// At least for now, this transformation is performed iff the paste
GC>   /// target is a wxTextCtrl.
GC> 
GC>   void Skeleton::UponPaste(wxClipboardTextEvent& event)
GC>   {
GC> ...
GC>       wxTextCtrl* t = dynamic_cast<wxTextCtrl*>(event.GetEventObject());
GC> 
GC> I'd like to consider a change like
GC> -      wxTextCtrl* t = dynamic_cast<wxTextCtrl*>(event.GetEventObject());
GC> +      wxTextCtrl* t = 
dynamic_cast<InputSequenceEntry*>(event.GetEventObject());
GC> 
GC> But wxTextCtrl is not the base class (as I naively anticipated it to be)...
GC> 
GC>   class InputSequenceEntry: public wxPanel
GC> NOT wxTextCtrl.....................^^^^^^^

 InputSequenceEntry is a composite control, so while it contains a
wxTextCtrl, is is not a wxTextCtrl.

GC> ...and for all I know this might be a better place to make a change...

 If we only need the replacements of newlines (and TABs) with semicolons to
happen in InputSequenceEntry, the best would clearly be to move the logic
for doing this inside this control itself.

GC> ...so we'll work more efficiently if I stick to my own specialty, and
GC> ask for help here, noting by the way that we don't want to break this:
GC>   void Skeleton::UponTestPasting(wxCommandEvent&)
GC>   {
GC>       wxTextCtrl* t = new wxTextCtrl(frame_, wxID_ANY, "Testing...");
GC>       ^^^^^^^^^^          ^^^^^^^^^^

 But, of course, the above would break this test case. IMHO the best would
be to just replace wxTextCtrl above with an InputSequenceEntry: after all,
if we want the replacements to work only in the latter, it doesn't make
any sense to test that they work in the former. Is there any good reason
not to do it?

 Also, perhaps this should be moved out of Skeleton itself and into the GUI
test suite?

GC> But let's say OXI for now and then change our minds after Oxi Day.
GC> Or should we do it sooner (if it's easy enough) because an end user
GC> might want to paste multiline text from one census into another?

 I can't answer this, all I can say is that doing the first change proposed
above (i.e. without the second "move out of Skeleton" part) would be quite
simple and IMHO couldn't possibly break anything not related to pasting.

 Please let me know if I should do it,
VZ