Geert, The boost error was due to me not building boost with icu support.
I have pulled your cpp branch and tried to build which was OK but had some errors when I used it. With the following changes at https://github.com/Bob-IT/gnucash/commits/fork_branch, I can import a csv file with no observed errors. You may already have noticed them but you never know. Now to look at the price importer... Bob On 10 January 2017 at 18:26, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > Op dinsdag 10 januari 2017 15:38:27 CET schreef Robert Fewell: > > Geert, > > > > Thank you for the comments, especially the date ones which now make > sense. > > I will have a look at my changes and why I made them as it may relate to > > changes I will need to the price importer. > > > You're welcome :) > > I have just pushed the most recent state of my cpp branch (minus a final > work > in progress) to my github repository. You may want to rebase to that one. > It > should present a more or less usable csv transaction import assistant. > > Note I don't expect you to take the whole transaction related code for your > price importer. You may follow the design obviously if it suits you as > well. > But I think there are a number of useful classes in there which you > probably > can reuse as they are. I'm thinking about the gnc-tokenizer class and its > subclasses for csv separated or fixed width column data. They should allow > you > to split your csv file in a table of values to be interpreted by a price > specific parser. For transaction importing this specific parser is > implemented > in the GncTxImport class (note the absence of "csv" in that name - I > believe > the class is generic enough to also handle transactions coming from qif or > ofx > data in the future by adding specialized tokenizers for these formats). > > The design principles in my csv importer are as follows: > - the assistant code is "dumb". It's responsible for displaying data and > passing user commands to the real parser. So it shouldn't make any > decisions > other than what's needed to properly display all the information (including > enabling/disabling options and buttons) > - the real intelligence is stored in the GncTxImport class, which is > responsible for everything related to the data. It will massage the data > found > in the input file into proper gnucash transactions. This class is > completely > gui-less, so it could potentially even be used from non-gui interactions, > such > as our python bindings (if someone would add the currently still missing > bindings). > - Some parts are delegated to helper classes. One such example is the > tokenizer class which handles everything from loading a file to splitting > the > data into a table of strings. From there GncTxImport takes over. The > settings > are also stored in a separate class to simplify loading and saving user > presets and switching between them. This is heavily based on your initial > work > to load and save these presets, mostly reworked into a c++ class and > redesigned a bit to make it a more central piece of the GncTxImport class. > > I hope this information will help you better understand the new csv > importer > and at the same time help you to model your own price importer, which can > probably be implemented less generically. I would keep the strict > separation > of gui and business logic though. Make your price importer class such that > it > can be used without a gui and let the gui interact with it by querying the > information it needs/passing the inputs it receives from the user. > > Regards, > > Geert > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel