Apache OpenOffice (AOO) Bugzilla – Issue 15509
Q-PCD affiliate: Clipboard format support for CSV
Last modified: 2013-08-07 15:15:35 UTC
So - it transpires that people like to cut and paste structured text into the spreadsheet, and it's really nice if the 'import text' dialog pops up so they can determine how it's formatted [ if it's more than a simple, single line ]. This trivial patch hooks it into your nice structure easily enough; it'd be nice to re-factor that method into a separate helper - if only that didn't involve changing a header.
Created attachment 6803 [details] improved plain-text paste dialog ...
Hi Niklas, this one's for you ? Frank
Falko, your idea was to have an additional, "fake", clipboard format. Michael's solution would instead open the dialog if there's more than one line of text in the clipboard. Do you still think we need the additional format?
FT->Niklas: After spending some more in-depth thoughts on this issue here is what came out ;o) We willl sticjk to our "fake" clipboard format solution because copying a single does not guarantee under all circumstances that one does not want to copy text only. It is very likely that one is pasting only one line from a CSV database to a spreadsheet. In this case the automatism will fail. P
So - to confirm; if I cut and paste multiple lines of CSV text from a random terminal / web-browser etc. it will all work right in 1.1 ?
For 1.1, nothing was changed (and won't be, now that the RC is already being built). This is all about 2.0. Of course this means the issue shouldn't be marked "fixed", yet.
Changed OS and issue type as well a prority. Since this feature is not covered by PCD priority has to be set to 4.
*** Issue 4040 has been marked as a duplicate of this issue. ***
*** Issue 4982 has been marked as a duplicate of this issue. ***
*** Issue 20913 has been marked as a duplicate of this issue. ***
Changed title for better finding
*** Issue 3184 has been marked as a duplicate of this issue. ***
*** Issue 21330 has been marked as a duplicate of this issue. ***
Modified title
*** Issue 22157 has been marked as a duplicate of this issue. ***
according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later.
*** Issue 34022 has been marked as a duplicate of this issue. ***
Given that we have a rather fine, working patch that's been shipping for many moons, is tested, works etc. - can we not go with that instead of a "wont-fix". You see how many duplicates there are here - right ?
Created attachment 18314 [details] new patch vs. 2.0
Yes this is the feature which is really missing. I work with statistival data very much and i shoul either everytime 1. copy data 2. go to notepad 3. save it 4. go to data import 5. find the saved file 6. import it which is too long. The "text to columns" feature from Excel would serve this much more better. Thanks Jakub
*** Issue 38754 has been marked as a duplicate of this issue. ***
Shouldn the votes of a closed duplicate issue be added > to the Open issue? I am ready to require our company > to use open office but I can not do that until closed > issue 4040 is in fact resolved.
issue 4040 (text to columns) is reopened because it could not be ensured that this Q-pcd could handles this too.
Does this mean that there is a chance you might commit something like my patch from 18 months ago now ;-) It isn't a darstadly plot to destroy the suite in patch form: honest :-) [ I happen to have needed it myself on several occasions ]
I wonder why this issue is not already resolved: on my UbuntuLinux (debian based) box, OOo comes with a patch that does the job. Why the same patch is not inserted in the main stream?
The patch is too simple ! - we need a more complicated approach ;-> Since I don't understand the 'fake clipboard format' approach, I'm sceptical that it will work pasting from common Unix applications over which we have no control - and where we simply get a big chunk of text - all too frequently. Similarly - yes, it doesn't handle a single row very nicely - but then, manually converting a single row of data to a number of columns is usually fairly trivial. Not committing the patch because it has 1 corner case you think could be easier - is condeming innumerable users to serious pain on the off-chance of avoiding hurting this tiny corner case. Sigh.
The patch is too simple ! - we need a more complicated approach ;-> Since I don't understand the 'fake clipboard format' approach, I'm sceptical that it will work pasting from common Unix applications over which we have no control - and where we simply get a big chunk of text - all too frequently. Similarly - yes, it doesn't handle a single row very nicely - but then, manually converting a single row of data to a number of columns is usually fairly trivial. Not committing the patch because it has 1 corner case you think could be easier - is condeming innumerable users to serious pain on the off-chance of avoiding hurting this tiny corner case. Sigh. ** This bug has ~25 duplicates if you count #4040# **
*** Issue 44517 has been marked as a duplicate of this issue. ***
I think the number of votes and duplicates is not reflected in the priority...
FT: Hi Niklas, can you please have a look on this patch. If it is really that simple change/addition then we should seriously consider to integrate this patch into OO.o 2.0. Or maybe this is something for 2.0.1?
FT: After talking with Niklas, who suggested to combine this feature with issue 39898 we decided to shift this patch/enhancement to release 2.0.1. In rough words: We will add a checkbox to the "Paste special" dialogue (on by default) that will show the CSV filter or a new HTML filter options dialogue. This will enable the user to define the formatting of his source text.
*** Issue 51792 has been marked as a duplicate of this issue. ***
FT: This issue will be handled (and solved) within issue i50670. Please close. Thx. *** This issue has been marked as a duplicate of 50670 ***
... and closed
Can you confirm that this issue was in fact fixed as part of i#50670# - to me it seems (as it always has done) that this is a totally different issue, and the spec. shows no sign of having this change. Only (nearly) a year since this was marked a 'duplicate' (IMHO) completely bogusly.
re-target to 2.0.4
Hi Eike, please have a look at this one. Frank
Created attachment 37229 [details] fix rendering
The 2nd patch fixes the rendering problems caused when doing the csv paste: this seems to be down to a bug in the method used to import that code. The patch fixes the code path such that we throw up a warning dialog (as expected) if the sheet is not editable, adjusts the range correctly, and calls Start/End paste (as the other importers do). HTH.
There was the idea to solve both issues together with a "filter options" button in the "paste special" dialog, which is why this was marked as duplicate. But the actual solution for issue 50670 is different, so, yes, this one is still open.
I'm back from vacation. There is not enough time to get this into 2.0.4, retargeting to 2.x Mathias (mmp on CC), is it acceptable from a User Experience team's view to have this "small solution" (instead of the "big import options button", which we won't get that soon) and invoke the CSV import dialog during paste if a newline is present in clipboard data? Maybe even if common field separators like comma/tab/semicolon are present? Eike
Mathias, As you're back from vacation now, this is a kind reminder to have a look at my previous comment in this issue and state whether UE would be satisfied with the small solution. Thanks Eike
Thanks for the call, Eike. AFAI-understand this issue we should implement it for OOo 2.1. No dialog change, no documentation change, no spec necessary. New behavior: If the clipboard contains structured text in the form of i) several lines, or b) text with typical separators like ';' then the Text Import Dialog is opened to allow to fine tune the interpretation of the text.
Started.
In CWS calc39: sc/source/ui/dbgui/scuiasciiopt.cxx 1.9.62.1 sc/source/ui/docshell/impex.cxx 1.36.62.1 sc/source/ui/inc/impex.hxx 1.11.282.1 sc/source/ui/view/viewfun5.cxx 1.41.62.2 Including (corrected) Undo from issue 45248 and modifications to handle overflows.
*** Issue 45248 has been marked as a duplicate of this issue. ***
Thank you Eike - you rock. Your customers are going to love you: really :-)
back to QA for verification
Actually this is a new feature, changing issue type.
Created attachment 39665 [details] Testcasespecification for Clipboardtest enhanced for CSV Import dialog on Paste Special of structured unformatted text
sc/source/ui/view/viewfun5.cxx 1.41.62.3 Sigh.. QA rejected this feature because of time constraints and automated testcases that use the clipboard and would had to be adapted. Temporarily disabled the condition, will enable for OOo2.2 again.
Grabbing issue again.
Accepting.
This is important. Not having it is one of reasons why I continue to use Lotus 123 for important work.
In CWS dr51 sc/source/ui/view/viewfun5.cxx 1.43.6.1
*** Issue 70865 has been marked as a duplicate of this issue. ***
In my opinion the "fake clipboard format" is the best solution for accessing the CSV import wizard. (Also when pasting single rows I want to be able to use the CSV import wizard. Note that also single rows can have many, many columns!)
Norbert2, see http://sc.openoffice.org/servlets/ReadMsg?list=features&msgNo=218
"When pasting unformatted text from the clipboard, either when it's the only clipboard format or selected under Paste Special, and the text consists of more than one line or contains at least one of the field delimiter characters comma, semicolon, tab or blank, then the CSV text import dialog is opened to allow detailed processing of the clipboard content." So I would also have a CSV dialog when pasting a single row with many columns (if delimiter characters are present, right? This is important for me. As I understand this will also lead to unwanted opening of the CSV dialog that the user has to confirm. Is it possible to design this function so that just conforming of that dialog leads to the same result as current OOo versions without that dialog? It would be a solution but I'm not a fan of such automatisms. If you implement this don't forget that it should also work when pasting unformated text using the drop down menu of the paste button! The text above only mentions "paste special".
Norbert2, > So I would also have a CSV dialog when pasting a single row with many columns > (if delimiter characters are present, right? This is important for me. Yes, that's correct. > As I understand this will also lead to unwanted opening of the CSV dialog that > the user has to confirm. Is it possible to design this function so that just > conforming of that dialog leads to the same result as current OOo versions > without that dialog? Done. No separator checkbox is preselected, just hitting enter will paste the entire content to the current cell. > If you implement this don't forget that it should also work when pasting > unformated text using the drop down menu of the paste button! The text above > only mentions "paste special". The button's result pasted is unformatted text if selected. So yes, it also works when pasting via the button. Btw, this issue is marked RESOLVED/FIXED and implementation is already done, just waiting to be built, QA'd and integrated. Eike
> No separator checkbox is preselected Actually the Tab separator is preselected now because that mimics the previous behavior without this feature, where an embedded tab splitted the text to different columns.
OK. This is what I mean.
Reassigning to QA.
found fixed on cws dr51 using Linux, Solaris and Windows build
Coming here from issue 73320 ... As much as this feature here might be important for people doing statistical work with Calc, it is disturbing and annoying for a lot of other use cases. Nowadays, whenever I want to copy some text into a cell, where this text comes from an editor, and contains spaces (that means: *always*), then the import dialog pops up. Argh. That's the typical case of "magic always hurts 50 percent of your users". I don't want OOo to know better than me what I want to do. If I paste plain text, I want OOo to simply paste it, instead of a dialog jumping out of the box and crying "Hey, see what other cool functionality I can offer here! Care to try it?" No, I don't care. Is there any chance we introduce an option (even without UI) which controls this behaviour?
Frank - sorry, norbert2 screwed you ... our original patch behaved in a more friendly fashion.
fs: This is why I would prefer the "fake clipboard format"-solution, too.
found fixed on master OOFm6 using Linux, Solaris and Windows build