I just want to point out what .cvs support entails for the benefit of those for whom this isn't immediately obvious.
.cvs refers to the low level format of the data -- just that the file of data consists of "records? delineated by <newline> and the records consist of "fields" delineated by commas. But there is nothing defining what data is in these fields and just as important, in what order. That means that an "import from .cvs" functionality requires more than just being able to accept data separated by commas. It needs a facility where the user gets to enter information specifying which fields to be included (and which possibly ignored) and in what order. That's the substantial component of a project to "import from .cvs". Especially since without a "guide" for the user on using* this "field specification component" likely to be beyond the abilities of many "end users". Michael D. Novack, FLMI * keep in mind that it's not SIMPLY "using" (how to specify the skipping fields and reordering fields. The "end user" is unlikely to know (initially) what are the required fields and their order. PS -- in it's simplest form, .cvs is an example of "positional;" rather than "keyword" data. However it is entirely possible that "keyword" type data could be stored in commas separated format (alternate fields are "field identifier" followed by "field data"). If the data is of that sort you don't need a field skipping and field reordering facility (a program can use the field identifiers to determine the fields it wants to put where regardless of order). However that isn't strictly speaking "cvs. data" in spite of the way delineated by commas. In other words, .cvs data and .cvs file don't mean EXACTLY the same thing. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
