Apache OpenOffice (AOO) Bugzilla – Issue 3687
Make CSV import/export filter settings persistent (e.g. the delimiter character). Very helpful for batch tasks.
Last modified: 2017-05-20 10:20:27 UTC
Under "Save As -> Save As Type -> Text CSV -> Export of text files -> Text delimiter" please provide a null text delimiter (no character) in addition to " and '
Hi Falko, I think this is something for you.
You can already manually enter any character instead of selecting one, or leave it empty in which case no text delimiter is used.
If the user can edit the delimiter character, the drop-box with " and ' is unnecessary.
It would be really wonderful if the delimiter you select could persist. I hate having to delete the delimiter every single time (but indeed I am glad that I _can_ have a null delimiter)
Make the setting that are used with the CSV import/Export filter persistent. Example: I need to import a 100 .CSV files with some special delimeters. Now every time I open one of them I have to re-set the import settings of the .CSV filter.
started
*** Issue 3766 has been marked as a duplicate of this issue. ***
*** Issue 21331 has been marked as a duplicate of this issue. ***
*** Issue 32651 has been marked as a duplicate of this issue. ***
enhanced summary, set keywords and reassigned issue according to RFE process
*** Issue 40552 has been marked as a duplicate of this issue. ***
Another year 2002 enhancement that would probably take no more than 8 hours to address. I urge you all to vote on an even greater injustice bug 4929. This is a BUG that has had no attention in 3 years.
bug 4925 oops
Created attachment 28401 [details] Proposed patch
Hi Daniel, could you have a look at this patch please ? Frank
type is now "PATCH". Please reconsider the target.
IMHO not only the "separated by" delimited case should be handled, but also the "fixed width" case.
Created attachment 29379 [details] Updated with er's requirements.
Hi Muthu, Right direction, but what I meant was to also include the column positions of the fixed width setting. Eike
Hi Falko, I added you to Cc of this issue because the patch introduces a new behavior, where dialog settings are stored in the configuration, and are not only remembered throughout a running OOo session. Does the User Experience team have any input on this topic? In case we wanted to add such behavior also to other dialogs I suggest to move the Office.Calc/CSVImport configuration group to an own subgroup of dialogs, e.g. Office.Calc/Dialogs/CSVImport Thanks Eike
Created attachment 29682 [details] updated to preserve the fixed width(s) also.
I guess Frank could be more helpful nowadays. To support the reconsideration of the target I set it to "not determined".
Ping? ;-) What about the new version of the patch, please?
Kendy, please be careful when fiddling around with targets! Changing it was probably ok in this case (2.x), though having set it to 'not determined' earlier was done on pupose. Thanks. As there was no input from Falko back in those days and he isn't with us anymore, I'm Cc'ing Matthias ('mmp') of the User Experience team now. Matthias, please read ------ Additional comments from er Fri Sep 9 03:23:25 -0700 2005 ------- whether UE has some input on that. Thanks Eike
The patch already exist since 2005, and until now not yet Integrated. and it has ms_interoperability, rfe_eval_ok, usability. I hope it is considered for OOo 2.2 Thanks
DR->MMP: Please comment on Eike's questions from Fri Sep 9 02:23:25 -0800 2005
Dear developers, any news on this enhancement?
The developers don't know. This issue waits for input from the User Experience team.
*** Issue 77215 has been marked as a duplicate of this issue. ***
*** Issue 77215 has been marked as a duplicate of this issue. *** ok, looking at the long history of this bug (3687) and its many friends I'm kind of despairing of ever seeing a fix for my issue (which is quite a different matter from choice of delimiter). anyway, the minimal fix for the lossy csv export after an import that I described in #77215 would be to offer the same export menu when selecting "save as" on an opened csv file that you receive when selecting "save as -> csv" for a regular calc spreadsheet. This would give the ability to uncheck "save as displayed". Ideally csv import than export should be as close to idempotent as possible.
seemingly I want the feature that user Abeelias considered a bug in #4925. I think my use case (importing csv files, editing, then exporting without loss of precision) is valid, and it is exactly how excel works on imported csv files.
I was sent to this issue for my question: is there a way to change the default separator char for csv-export dialog? why not user-depend-config-values for import & export like this: -list-of-delimiter-chars (example: "') -list-of-separator-chars (example: ,:;{TAB}{SPACE}) -default-delimiter (e.g. first of list) -default-separator (e.g. first of list) -use-separator with the values: import-depended, always-default -use-delimiter-chars: import-depended, always-default and a default like Excel does? Sincerely yours
Note Issue 75076 and the patch (mypatch.diff) there. Needed to fix some import problem.
(beware: mypatch.diff is a reversed one....) Adding eknagy to CC
@mmp: Matthias, any input on my #desc22 comment of Fri Sep 9 10:23:25 +0000 2005 directed to Falko? Repeating here: [...] the patch introduces a new behavior, where dialog settings are stored in the configuration, and are not only remembered throughout a running OOo session. Does the User Experience team have any input on this topic? In case we wanted to add such behavior also to other dialogs I suggest to move the Office.Calc/CSVImport configuration group to an own subgroup of dialogs, e.g. Office.Calc/Dialogs/CSVImport Thanks Eike
move target from 2.x to 3.0
reassign issue to fl. Frank, can you please take action on it, since this is voted patch ?!
With feature freeze delayed untill 15th of March we have a chance of integrating this patch for 3.0.
@kpalagin: No, even if feature freeze was delayed (check back with the releases@ mailing list, the delay was redrawn) there would be no chance to get this in. It would need yet another CWS that had to be QA'ed. There wasn't even a decision whether we want this patch as is, we're still awaiting UX input.
muthusuba: I suggest to change the behavior of this patch this way: change if( nCharSet >= 0 ) aLbCharSet.SelectEntryPos( nCharSet ); to if( !bPreselectUnicode && nCharSet >= 0 ) aLbCharSet.SelectEntryPos( nCharSet ); or to if( !bClipboard && nCharSet >= 0 ) aLbCharSet.SelectEntryPos( nCharSet ); Charset field is disabled in "Text Import" and "Text to Column" modes (bClipboard and bPreselectUnicode in both case). Using the character set previously selected in "CSV Import" mode may cause data loss (see attached screen shot) and it's of course an UX issue.
Created attachment 52723 [details] Data loss example
rail, I am sorry, but i didn't clearly understand: if( nCharSet >= 0 ) aLbCharSet.SelectEntryPos( nCharSet ); changes the 'Character set' - which can be manually changed if required. But in the screen shot I see the field to be disabled (how?!). thanks! muthusuba
muthusuba, it's disabled by ScImportAsciiDlg::SetTextToColumnsMode() in the same file, when you call this dialog via Data - Text to Column (introduced in 2.4).
rail, hmm...that's interesting...any idea on the reason for doing that? That would solve our problem, i guess. muthusuba
The reason is simple, clipboard is in unicode always, so there is no need to choose the character encoding. bClipboard is true if we use text from clipboard, bPreselectUnicode is true if unicode characters were "sniffed".
we'll have to do that for 'storing' also then - thanx rail!
Created attachment 53246 [details] revised patch to disable loading and saving of dialog settings
The revised patch disables loading and saving of the dialog settings when the dialog is launched for the text-to-columns functionality. We needed to do this to address several bug reports where the character set was incorrectly set to 'Unicode' when importing a csv file. Here is the downstream bug report: https://bugzilla.novell.com/show_bug.cgi?id=376473
This issue is important and listed on the quarterly review for Calc: http://wiki.services.openoffice.org/wiki/2008_Q2_Review_of_Spreadsheet_Project
FL: New target.
Any news with integration of this patch?
I guess for whatever reason we missed 3.1 with this enhancement. Is it possible that we do not miss 3.2?
remove mmp
I'd really like to see this integrated in the next release of OOo. We seldom use simple comma in CSV, but rather semicolon for exemple :)
what kind of input is needed for this issue from User Experience ? This issue seems to be translation relevant, there move target to 3.2 :-(
See my comments in #desc22 from er Fri Sep 9 10:23:25 +0000 2005 "[...] the patch introduces a new behavior, where dialog settings are stored in the configuration, and are not only remembered throughout a running OOo session. Does the User Experience team have any input on this topic? In case we wanted to add such behavior also to other dialogs I suggest to move the Office.Calc/CSVImport configuration group to an own subgroup of dialogs, e.g. Office.Calc/Dialogs/CSVImport" Actually that was a question whether we may need some "store settings / forget settings / forget temporarily" or whatever buttons, and if storing/retrieving dialog settings would be expanded to a more application wide behavior in future, to not end up with some "island solution". If UX doesn't have any input on this we may as well proceed without. However, I'd still suggest to use the configuration path Office.Calc/Dialogs/CSVImport nevertheless, just in case we'll add other dialogs later.
I think it is common sense that storing dialog settings does make sense. Normally OOo stores settings for runtime of the program only, but in this case is makes sense to store them persistently, because a csv import is often a periodically recurring task. Most times the imported csv files will have the same format, so restoring the latest defaults makes sense. Even if the csv format changes the restored settings will not generate more work for the user, but saves time if the format keeps unchanged. Resetting or explizit storing/loading of settings sems to be overkill due to the limited settings of this dialog.
*** Issue 14675 has been marked as a duplicate of this issue. ***
@kohei: please go ahead in one of your next CWSs for OOo3.2, thanks. Note my comment about the configuration path Office.Calc/Dialogs/CSVImport above.
Do let me know if I can do anything for this.
Kohei, do you have some expected date when you integrate the patch so that we do not miss 3.2? Regards, KP.
not at the moment. When is the feature freeze for 3.2?
http://wiki.services.openoffice.org/wiki/OOoRelease32 2009-09-21 Branch off date (UI and feature freeze) It will come much faster than we expect.
Spec is now available here: http://wiki.services.openoffice.org/wiki/Calc/Features/Numbers_import_for_plain_text_files The development is on-going in koheicsvimport cws.
fixed in koheicsvimport cws.
re-assign to oc for qa.
adjusting target according to cws target
verified in internal build cws_koheicsvimport
(Hopefully, this is the right place to enter these comments) I think this issue needs to be solved (from the user's perspective) as follows: 1) There needs to be a way to persistently configure the default settings. This could be by making Calc's Text Import dialog's settings persistent or by having a Calc Import tab in the Options dialog. 2) There needs to be a way to choose to use the (saved, persistent) default settings without the Text Import dialog being displayed at all, when opening a new file. What I want to do is to start Calc from the command line (or via a File Manager by selecting a csv file) and have the specified file loaded into Calc without any Text Import dialog at all, using the default settings which I have previously chosen.
@jrw32982: You need to open up a new issue for that. This issue has already been resolved, verified, and is done for.
Hi I'm a German user of open office. The default setting for exporting csv files is ";" as field delimitor and "," as decimal delimitor. Unfortunately, the bugfix did not seem to work for my version. As long as i use "save as" and "edit filter settings", everything works fine, and he saves it in the format i used latest. Yet when i simply use the "save" button, he always saves in the german format (";" and ","), even when i changed the format before to "," and ".". Language settings do not change this behaviour. Best regards Thio
Is this the same thing? Version: 4.1.3.2 Build ID: 4.1.3.2-4.fc19 (old in fedora?) I was unable to categorise this both into components open-import and save-export. To duplicate: Try reordering this series of words: AUDCAD,AUDCHF,AUDNZD,AUDUSD,CADJPY,CADCHF,CHFJPY,EURUSD,EURGBP,EURAUD,EURCHF,EURJPY,EURNZD,EURCAD,AUDJPY,GBPUSD,GBPCHF,GBPJPY,GBPAUD,GBPNZD,GBPCAD, To do this I: - saved as a .csv from a txt editor, - imported with , delimit - right click copy/paste special transpose - try to save... - find I can't export in the same format file as I imported I think the best behaviour would be: - detecting the delimiting, - remembering this delimit - offer the option to export in the same format as what it was imported with, ideally with a preview