Am Sonntag, 24. Juni 2007 20:22 schrieb Chintan Agarwal: > Thanks for that information. I could not find the declaration of > Transaction structure(or its un-typedefed form) per say but from the > functions in the file, could gather the variable types present.
That is intentional. We don't use direct access to the structure anywhere in gnucash, and you shouldn't use that, too. Instead, all access is done solely by the accessor functions in Transaction.h -- that's the whole point of that file. Do you have doxygen installed? Run "make doc" and a HTML documentation will be created in src/doc/html/index.html; in that documentation, browse to "Files" and go to "Transaction.h". This should give a usable overview of what can be done with a Transaction*. Having said that, there is also the header file src/engine/TransactionP.h where you can observe the actual data fields of the Transaction structure. But as I already mentioned, the structure must not be accessed directly from anywhere else in gnucash. > I think that for QIF importer, we could have a simpler structure, akin OFX > importer wherein the function void gnc_file_ofx_import (void) (in > /src/import-export/ofx/gnc-ofx-import.c)is the top-level function. Sounds okay. > In such > a top-level function there are basically three steps:- > 1) Creating a context for the input data(done by QIF context) > 2) Parsing the data(done by QIF parser written in /src/import-export/qif) > 3) Integrating the parsed data into the Gnucash accounts, actions like > matching, mapping etc.(as pointed out earlier, this is done simply by using > functions in import-main-matcher.h, specifically the function > gnc_gen_trans_list_add_trans(...)). > As for the frontend, it would be there only in step 1 as after that the > parsing process( in the backend) starts and completes. As a high-level description this is fine. However, I think problems will arise in the details, especially for the QIF format. But I would suggest you should commit the first code parts to your branch so that Josh and others can comment on that directly. > Some questions:- > 1) Do the above three steps miss out something vital for QIF import? Yes - the QIF file format has a whole bunch of nasty ambiguities. For that reason, there are multiple places throughout the importing process where the user might have to be asked to resolve some ambiguities (e.g. date format Year/month/day vs. Month/day/Year vs. whatever). The existing OFX importer is an example for you to start with, but QIF needs much more interaction with the user due to these ambiguities compared to the more modern OFX format. Your proposal above might still be sufficient, but please keep in mind you will have to add more user interaction along the way. > 2) The top-level function that would be made should be by what name? In > other words, which function call results in the QIF import process being > trigerred? If you're adding your code in the qif-import directory, just start by modifying the content of the gnc_plugin_qif_import_cmd_new_qif_import() function and have it create your new dialogs instead. > 3) Does GNUCash use the standard GNU indentation format? Currently probably yes, but it's up to the individual developer. There are efforts to unify the indentation. Once these are put in place, clear guidelines about the indentation will be given. As long as you haven't been told anything more specifically, just pick your favorite indentation and stick to it. GNU format is just fine. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
