Missing screen/info on tutorial

Hi, Tutorial first chapter, Putting it all together section, while describing the creation a a new book, the screen regarding the New book options is not mentioned/described. Regards, Pedro. ___ gnucash-devel mailing list gnucash-devel@gnucash.org

Re: Missing screen/info on tutorial

Done, thank you John. Regards, Pedro. Sáb, 2016-01-23 às 07:15 -0800, John Ralls escreveu: > > On Jan 23, 2016, at 3:27 AM, Pedro Albuquerque > > wrote: > > > > Hi, > > > > Tutorial first chapter, Putting it all together section, while > > describing the creation a

Re: Missing screen/info on tutorial

> On Jan 23, 2016, at 3:27 AM, Pedro Albuquerque > wrote: > > Hi, > > Tutorial first chapter, Putting it all together section, while > describing the creation a a new book, the screen regarding the New book > options is not mentioned/described. Pedro, Please check

Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

I'm tackling this bug as my first contribution to the project and have a few technical questions. To track pending matches within the current import process there are two main possibilities that come to mind. I'm almost sure the first is a bad practice, but I don't want to make assumptions about

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

> On Jan 23, 2016, at 5:18 PM, Jesse Olmer 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? >

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

> 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

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

> On Jan 23, 2016, at 2:37 PM, Jesse Olmer wrote: > > I'm tackling this bug as my first contribution to the project and have > a few technical questions. > > To track pending matches within the current import process there are > two main possibilities that come to

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

> On Jan 23, 2016, at 4:56 PM, Tracy wrote: > > > > On 1/23/2016 19:46, John Ralls wrote: >> >>> On Jan 23, 2016, at 2:37 PM, Jesse Olmer wrote: >>> >>> The second route (and the one I've already started on) is to have a >>> new object which

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

On Sat, Jan 23, 2016 at 10:13 PM, John Ralls wrote: > >> On Jan 23, 2016, at 9:44 PM, Jesse Olmer wrote: >> >> >> 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

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

On 1/23/2016 19:46, John Ralls wrote: On Jan 23, 2016, at 2:37 PM, Jesse Olmer wrote: The second route (and the one I've already started on) is to have a new object which ref counts pending matches (essentially, a map of match info's to their ref count and some

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

On Sat, Jan 23, 2016 at 7:26 PM, John Ralls wrote: > >> On Jan 23, 2016, at 5:18 PM, Jesse Olmer wrote: >> >>> Why not just add a gboolean "used" attribute to _matchinfo, set it true >>> when the corresponding transaction is used in a match and

Re: Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

> On Jan 23, 2016, at 9:44 PM, Jesse Olmer wrote: > > > 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