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

[Vadim Zeitlin]

On Sat, 23 Feb 2008 15:15:34 +0000 Greg Chicares <address@hidden> wrote:

GC> Ah. I had thought "Link" was some specialized format that
GC> would require support code in wx. But it's really just a
GC> bit of generic glue that binds three strings together to
GC> represent DDE via the msw clipboard. And in 'main_wx.cpp',
GC> Skeleton::UponPaste() isn't using anything like the full
GC> capabilities of DDE; it's just saying
GC> 
GC>  - if data looks like DDE (because it has "Link" data),
GC>  - then read the clipboard as wxDF_TEXT (and invoke some
GC>      special '\r' reformatting inside lmi)

 Actually the code is not concerned about DDE, it just uses "Link" as an
indicator that the data belongs to Excel. But this is completely wrong as I
(very belatedly) realize, "Link" is not at all Excel-specific and it would
be much better to check for e.g. CF_SYLK which is also always present if
the data was provided by Excel and should be also provided by other
spreadsheet programs as SLK is a relatively universal format for
spreadsheet data exchange (comparable to RTF used by word processors).

GC> And, I hypothesize, it would actually be an improvement
GC> to ignore the "Link" stuff and do the '\r' reformatting
GC> unconditionally. Here's why:
GC> 
GC>  - open ms 'excel'; enter a column of data; copy it
GC>  - paste it into lmi
GC> 
GC> It's reformatted when it's pasted. But now...
GC> 
GC>  - close ms 'excel'
GC>  - paste into lmi again
GC> 
GC> Now it's not reformatted. E.g., "X\rY\rZ\r" is pasted as
GC> the single character "X". I guess closing the spreadsheet
GC> ended the DDE conversation and removed the "Link" format
GC> from the clipboard, leaving only the text there.

 I don't think DDE is involved at all here, while the "Link" is documented
in DDE section of the MSDN, it's really just a clipboard format and can be
used here without any reference to DDE. In any case, closing Excel does
remove the data in all the formats except the text one(s) as can be checked
with ClipSpy[*] so we'd still have the same problem if we were checking for
CF_SYLK.

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?) 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?
VZ


[*] ClipSpy is a very useful tool for diagnosing various clipboard
    problems, see http://www.codeproject.com/KB/clipboard/clipspy.aspx