Re: [lmi] Where's 'wxDataFormat("Link")' implemented?

[Greg Chicares]

On 2008-02-23 15:44Z, Vadim Zeitlin wrote:
> On Sat, 23 Feb 2008 15:15:34 +0000 Greg Chicares <address@hidden> wrote:

[changing '\r' delimiters to ';' when pasting to a text control:
prior to 20080224T1711Z, this transformation was performed only
if the clipboard contained data format "Link", which leads to
odd nuances in behavior]

> GC> A user could be puzzled by that, so I think I'll just simplify
> GC> the paste handler to do the '\r' reformatting always.
> 
>  It could be argued that it isn't completely unexpected that closing the
> program owning the clipboard data degrades the "quality" of what remains on
> the clipboard. E.g. you don't get the same result if you paste data from
> Excel into Word neither if you close Excel first.
> 
>  OTOH in this particular situation I really don't see any harm in always
> replacing "\r\n"s with semicolons as we're pasting the spreadsheet columns
> into single line text controls anyhow (don't we?)

Correct. The whole point is to translate a row or column vector
to a single semicolon-delimited string that's displayed in a
single-line text control.

> and putting "\n"s into
> them doesn't work in any case. So not doing the translation results in loss
> of data, from the user point of view, while doing it can at worst be a
> minor inconvenience (how hard can it be to delete the text after the first
> semicolon if you pasted something other than spreadsheet data by mistake?).
> 
>  So IMHO the best would be to always do the translation but only do it for
> single line controls. Failing that, i.e. if we really want to ensure that
> we only translate the data coming from a spreadsheet, we should be
> definitely using CF_SYLK and not "Link" to check for it.
> 
>  What do you think?

Changed 20080224T1711Z. I chose to do the translation for all
text controls, because lmi input never [1] uses wxTE_MULTILINE.

When I recently refactored all wxTheClipboard stuff into a couple
of generic routines, I noticed that CensusView::UponPasteCensus()
was already performing a comparable (but deliberately different)
translation--unconditionally, without regard to any data format
other than plain text. The CensusView::UponPasteCensus() user
documentation [2] gives an example of pasting plain text. Keeping
those behaviors similar is another reason for ignoring "Link" in
the paste-to-text-control case.

Thanks for pointing out SYLK--here's a link for others who might
not have encountered it:
  http://en.wikipedia.org/wiki/SYmbolic_LinK_(SYLK)
I've seen illustration systems that are tightly integrated with
the One Spreadsheet to Rule Them All, using "ole" or whatever
they call it now. SYLK could be a first step in that direction,
but I think that would be a mistake--because it'd be a tease for
some users, who'd then demand ever-closer spreadsheet bindings.

---------

[1] wxTE_MULTILINE "never" used: lmi input dialogs are intended
never to use multiline text controls. There's no compelling use
case for them, and they introduce complexities: their default
keyboard handling is unusual, for instance. Furthermore, when
a '\r'-delimited vector is pasted into a multiline text control,
should the delimiters be translated (a) always? (b) iff the data
"appears" to come from a spreadsheet? (c) never? It's better not
to use them at all so we don't have to think about these issues.

Yet that style has been used in one '.xrc' file, at the behest of
one former user, over my objection and with a disclaimer of any
guarantee as to its behavior. Cutting and repasting multiline
text there has the effect of redelimiting it.

[2] "user documentation": The legacy system's "help" files, soon
to be reimplemented with wxHelpController.