Re: [lmi] Pasting between multiline edit controls

[Greg Chicares]

On 2016-05-12 17:35, Vadim Zeitlin wrote:
> On Wed, 11 May 2016 22:50:57 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I applied your patch here:
> GC>   
> https://github.com/vadz/lmi/pull/12/commits/03df797d18ac2be60ecdc5a6d27380baf8e74381
> GC> 20160511T2238Z, revision 6580.
> 
>  Thanks!
> 
> GC> Returning to this after some months, I was surprised to see that this
> GC> desirable new behavior:
> GC> 
> GC> +/// Type wxTextCtrl: Paste literal clipboard contents. Text delimited
> GC> +/// with "\n" or "\r\n" is shown on distinct lines in a multiline text
> GC> +/// control with all delimiters removed; in single-line text controls,
> GC> +/// all delimiters are replaced by RETURN_SYMBOL.
> GC> 
> GC> ensued from adding just one line:
> GC> 
> GC>   if(!dynamic_cast<InputSequenceEntry*>(t->GetParent())) {return;}
> GC> 
> GC> but that's the behavior that {return;} gives now that the RETURN_SYMBOL
> GC> support is in wx, right?

Let me guess the ultimate answer before you say any more. Here's what I
think happened: across a series of emails, I presented some hackish and
unsuccessful ideas, and you made it all work (which is good) and then
folded the comments from my feckless strivings into your patch...and it
is that folding, it is those comments, that created my confusion here.

I infer this because it seemed really weird that your patch added a
"TODO ??" comment that was unrelated to the task at hand. Searching the
email thread, I saw that I was that comment's original author.

(I've since resolved the comment, or so I think, by trimming leading and
trailing semicolons from strings pasted into input-sequence controls. I
figured that would gracefully disregard empty cells at the top or bottom
of a spreadsheet column that's copied and pasted. Maybe that's good, or
maybe not. Arguments for removing that behavior (and the similar behavior
before that change--removing semicolons at one end only, I forget which)
are: (1) DWIM is generally an error; and (2) today I wanted to cons up a
long input sequence, to test sequence-editor improvements, so I took the
sequence I had in one control:
  100000; 110000; 120000; 130000; 140000; 150000
then added a semicolon at the end, copied the modified string to the
clipboard, and did paste-paste-paste...and the trailing semicolon
vanished. This makes my change seem idiot-friendly and user-proof.)

And that, I suppose, is how we got a comment:
> GC> +/// Type wxTextCtrl: Paste literal clipboard contents. Text delimited
> GC> +/// with "\n" or "\r\n" is shown on distinct lines in a multiline text
> GC> +/// control with all delimiters removed; in single-line text controls,
> GC> +/// all delimiters are replaced by RETURN_SYMBOL.
describing this magical new behavior that is documented to arise
when all code that might have done it is removed. The only possible
explanation is that you did it in wx, but...

>  No, this is very mysterious because there is no RETURN_SYMBOL support in
> wx. I wanted to add support for it in wxDataViewCtrl only, but didn't do
> even this. I don't think adding it to wxTextCtrl itself would be desirable
> and I definitely didn't do this.

...so I think the comment is false. Now I should probably remove that
comment (as well as the code described in the parenthetical paragraph
above, which addressed a different comment that wormed its way into
the patch by the same means).

>  If you're really using the RETURN SYMBOL U+23CE ("⏎", see
> http://www.fileformat.info/info/unicode/char/23ce/index.htm) in the text
> control, I have no idea where is it coming from. Notice that MSW does show
> a black bar instead of new lines in single line EDIT controls natively when
> not using themes, but this is a completely different symbol and it is not
> shown when using XP or later with themes.

I was merely trusting the comment--I didn't actually test the code.

I figured I might apply this patchset
  https://github.com/vadz/lmi/pull/27/
first, and then revel in the ease of testing this with multiple skins,
some with multi- and some with single-line edit controls. But then I
thought I should apply this one
  https://github.com/vadz/lmi/pull/23/
first, to avoid breaking the makefile changes in #27. Of course, there
I ran into the github obstacle that you helped me with in personal
mail earlier, so first I started testing this patchset
  https://github.com/vadz/lmi/pull/25/
(in doing which I found the semicolon-paste-paste-paste issue above)
and I think I'll write up my findings on that topic first, and then
return to this patch #12 which seemed so simple.