From Microsoft Access I remember a pretty convenient preview window for importing csv or xls files. It allows selecting the separator (with a good automatically detected default setting) and shows a preview of the first lines. Sorry, no screenshot attached. I don't have MSAccess in the moment.
(01-04-2016, 02:21 PM)Zuberman Wrote: [ -> ]I'm not sure it's a good idea to use comma as a delimiter for anything. Users may want to put commas in other fields, and it increases the complexity if I have to add special delimiting for one field but not others. If people would still prefer comma over |, then I will certainly consider it.
What do you suggest for separating multiple items? Maybe a semicolon for that and tabs and something else for field separators?
Thanks for the update and all the hardwork you put into it!!
I'm still leaving the pipe symbol | as the separator for multiple values for a particular column. If people would prefer a different character, I'm open to changing it, but I think that character works fairly well in practice. The column delimiter is now automatically calculated in v1.3.2.
I have my companion set for automatic updates. Update to 2.2.3 has not shown up?
I have clicked on 'Check for updates'
It is not showing that an update is available and is showing version 2.2.2.?
I have never had to do anything in the past to get an update, am I missing something?
(01-05-2016, 06:46 PM)Zuberman Wrote: [ -> ]I'm still leaving the pipe symbol | as the separator for multiple values for a particular column. If people would prefer a different character, I'm open to changing it, but I think that character works fairly well in practice. The column delimiter is now automatically calculated in v1.3.2.
I actually prefer the semicolon for multiple items. It's practically obsolete in current writing use so there should be no clashes. It isn't a special character and you can reach it more easily to type on keyboards (for those like me who will do a lot of csv editing at a PC, on German keyboards it's on the same key as a comma).
And not very importantly but still it's consistent with other applications using semicolons for multiple entries fields (Calibre and Mediamonkey come to my mind).
So one vote for semicolon from me. Maybe some more weigh in, too.
The problem is that I have to choose something for delimiting values that doesn't clash with what can be potentially used for column delimiting. People here indicated that they would like to use semi-colon for column delimiting and it does seem to be a popular use for that. If I used semi-colon for value delimiting, then it certainly could not be used as a column delimiter.
gerryfitz - I forgot to update the file which indicates what the latest companion pro version is. I just edited that file so you should see the update download automatically now. Sorry about that!
Mike
(01-06-2016, 04:37 AM)Zuberman Wrote: [ -> ]gerryfitz - I forgot to update the file which indicates what the latest companion pro version is. I just edited that file so you should see the update download automatically now. Sorry about that!
Mike
Thank you.
Gerry
Edit: ah cancel that, I just disconnected and reconnected and now it's working. So all good.
Ah, in the companion app, the library search function is no longer working for all of the tabs, except for the Songs tab where it is working. I have it sorted by All Fields.
Is there a fix in the works for this? Thanks
It seems to work just fine for me. If I go to any of the tabs and type in text, it filters the songs. Is anyone else experiencing a problem filtering with version 2.2.3? If so, are you running Windows XP, 7, or 10?
Thanks,
Mike
Hi all, just catching up. It's very cool that MSP now supports CSV-based import of multiple songs from a single PDF. However I don't understand why there has been a lengthy discussion about which delimiter to use.
(01-06-2016, 04:36 AM)Zuberman Wrote: [ -> ]The problem is that I have to choose something for delimiting values that doesn't clash with what can be potentially used for column delimiting. People here indicated that they would like to use semi-colon for column delimiting and it does seem to be a popular use for that. If I used semi-colon for value delimiting, then it certainly could not be used as a column delimiter.
Sorry, but I disagree with your assumptions here. Whichever delimiter character you settle on, there will always be at least one case where someone needs to use that delimiter within a song title or other data field. So you can never guarantee avoiding all conflicts simply by carefully deciding the delimiter. But this problem was solved in CSV decades ago!! That's the whole point of quoting, which is very clearly explained in
https://tools.ietf.org/html/rfc4180 and also demonstrated in the README for my own CSV index project:
https://github.com/aspiers/book-indices
So I would strongly vote for keeping the default delimiter character as a comma (after all that's what the C in CSV stands for), and simply ensure that your parser understands quoting of fields which contain commas. Solved!
Having said that, of course it does not do any harm to also support multiple delimiters. But supporting field quoting is absolutely essential regardless of which delimiter you use.
Okay, I'll add support for quoting values. Either way, my code is still set up to dynamically determine the delimiter. It just looks for whatever character is used to separate the columns on the first line.
Mike
(01-20-2016, 02:51 AM)Zuberman Wrote: [ -> ]Okay, I'll add support for quoting values. Either way, my code is still set up to dynamically determine the delimiter. It just looks for whatever character is used to separate the columns on the first line.
Mike
Great thanks Mike - dynamically determining it is a really nice extra feature!
(01-20-2016, 02:51 AM)Zuberman Wrote: [ -> ]... my code is still set up to dynamically determine the delimiter. It just looks for whatever character is used to separate the columns on the first line.
That is a rock solid approach, given that MSPro
requires the headings line.
Summarizing.
The CSV is a text file, UTF-8 encoded.
Records (lines) are separated using any of the established line endings (LF (ASCII 10), CR (ASCII 13) or CR+LF) but only one of these line endings should be used for all records. The last record of the file should have a line ending too.
Fields are separated by a separator character that defaults to comma (ASCII 44), but will be dynamically determined while processing the first (headings) record. Fields that need to contain the separator character should be quoted using double quotes (ASCII 34). If a quoted fields need to contain quotes itself, see RFC 4180.
The fields of the first record (headings record) designate the names (interpretation) of the fields of the rest of the records.
As a minimum, each record should contain the name of a song title and the page range.
Given that page ranges frequently contain commas, the choice for comma as separator is suboptimal since it will require many page ranges to be quoted. Therefore it is advised to use semicolon (ASCII 59) instead.
@aspiers: Would you consider to include the above in your README?