On Sat, Jan 23, 2016 at 7:26 PM, John Ralls <[email protected]> wrote: > >> On Jan 23, 2016, at 5:18 PM, Jesse Olmer <[email protected]> wrote: >> >>> Why not just add a gboolean "used" attribute to _matchinfo, set it true >>> when the corresponding transaction is used in a match and exclude the >>> instance from the match_list if its used attribute is true? >> >> I think there's two problems with that. _matchinfo instances are not >> shared across multiple transactions, they're created in >> split_find_match during the transaction initialization, so we can't >> use it to track whether any other instances have it as a pending >> match. The second problem is that whatever common data location is >> used needs to be able to ref count because multiple transactions could >> have the same best match based on the heuristic. A simple bool causes >> a problem when the user goes into the match picker for one of these >> transactions and changes it to a different item - we can't just set to >> false because it could still be a match for another transaction. >> >> Additionally, I think it's probably going to be useful to be able to >> indicate to the user whether the pending match is an automatic or >> manual selection, so having that reference back to the >> _transactioninfo(s) or pulling that data along in a new object would >> be necessary. > > Ah, I see that match_info is private to transactioninfo, so the list of > already-matched existing transaction has to be maintained outside of > matchinfo, and the transactioninfos are all loaded at once at the beginning, > so that's the wrong list. > The right one is the GtkListStore *store in import-match-picker.c. How about > keeping a GHashTable of GUIDs of transactions or splits, which ever is > easier, that have already been matched and filter out adding any transactions > whose GUIDs are in the GHashTable? There's already a guid_hashtable_new() for > you in src/libqof/qof/guid.h. >
Yeah that's essentially what I'm doing so far (although it'll need a bit of a rewrite if C++ isn't cool in maint). Instead of a hash table I'm using an unordered_map<GUID, TypeWhichDoesRefCountAndMatchTypeIndicator> which lives in _main_matcher_info and gets passed in to each match picker instance via gnc_import_match_picker_run_and_close. Filtering & display happens where you'd expect in match_update_match_model, and refcount updates are handled in the result of gnc_import_match_picker_run_and_close. Having to switch to C will take me about a day but hopefully I'll have something ready tomorrow. On Sat, Jan 23, 2016 at 4:56 PM, Tracy <[email protected]> wrote: > > Or display an indicator showing that it has been previously matched (in case > someone wants or needs to match two imported transactions to the same > existing register transaction).... No worries Tracy, that part's already done (http://i.imgur.com/XYVX5hp.png). It's just handling the pending matches in the current import that's the more difficult part. _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
