Register code question
I am debugging the register code and trying to figure out why bogus message boxes can appear, and also why crashes occur in certain cases. I believe that I've figured it out the sources of these problems, but I have a background question to ask before proceeding with a fix. These problems seem to stem from the way that the "pending_trans_guid" is used when entering a brand new transaction. Can anyone explain the intended use of pending_trans_guid where new transactions are concerned? I came across some comments in split-register-load.c which appear to shed some light. When the bottom line of the register is created (where the user would start entering a new transaction), a new transaction with a single blank split is tied to it but not marked pending: /* We don't want to commit this transaction yet, because the split doesn't even belong to an account yet. But, we don't want to set this transaction as the pending transaction either, because we want to pretend that it hasn't been changed. We depend on some other code (somewhere) to commit this transaction if we really edit it, even though it's not marked as the pending transaction. */ So it seems the intention is to never mark a brand-new transaction as the pending transaction. Yet a few routines DO set the brand-new transaction as pending, such as the autocompletion routine gnc_split_register_auto_completion() in split-register-control.c, and a couple of other routines that perform split deletion. So does anyone know why some forms of editing (autocompletion, deleting a split) cause the brand-new transaction to be marked as pending, while all others, including the typical practice of simply typing a transaction in, do not? What is the correct practice? Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions
On Wed, Oct 15, 2008 at 8:49 AM, Josh Sled <[EMAIL PROTECTED]> wrote: > "Tom Browder" <[EMAIL PROTECTED]> writes: >> I would like to see the scheduled transactions (sx) capability >> enhanced (see enhancement bug # 521285) to be more like Quicken. I ... > Why is a split-pane in the Account tab better than the existing > since-last-run (SLR) dialog (or maybe moving that dialog into a tab)? Probably no better--that's just the way Quicken does it. In fact, I think I like your tab idea better. > Do you really need to see both things at once (a main motivation for a > split-pane)? Otherwise, I fear the page wouldn't be big enough to see > either. Yes, I do: I'm used to entering one scheduled transaction at a time as I enter transactions into my various accounts (particularly my checking account register). But looking at the sx tab and flipping back and forth to the pertinent account tab should work fine. > What's the benefit of splitting up the upcoming transactions across > separate tabs (by account)? Instead, maybe, allowing an Account-based > filter on the existing SLR page? Just to unclutter the sx display--I really used scheduled transactions a lot in Quicken (e.g., quarterly dividends for stocks). Filters would work, and keep each filter result in its own new tab--lazy evaluation results saved for the session. But rather than doing one filter at a time I would just split into accounts from the get go (or maybe a selection on a per account basis, or maybe a user-preference for persistent settings). > One thing that people regularly ask for is – in the editor for a > particular SX – to see the upcoming instances, so that they may quickly > schedule something forthcoming. This should be pretty easy to do, by > simply generating the instance model through some configurable date in > the future (30 days? 60 days? drop down? as a function of the > frequency of the SX?). Unfortunately, there doesn't seem to be a way to > just generate the instance model for a single SX, but that should be > straightforward to add in. I'll be glad to investigate if I get anywhere on the other needs. > Anyways, I'm happy to help, but my response time might not be very low. Thanks for the helpful words, Josh, and I understand the time thing! Regards, -Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions
On Wed, Oct 15, 2008 at 8:07 AM, Charles Day <[EMAIL PROTECTED]> wrote: ... > Congratulations on taking this up! I don't know anything about the sx code, Thanks for the enthusiastic vote, Charles. -Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions
"Tom Browder" <[EMAIL PROTECTED]> writes: > I would like to see the scheduled transactions (sx) capability > enhanced (see enhancement bug # 521285) to be more like Quicken. I > would like to see a split-pane in the account window showing due and > buttons to push like 'enter', 'edit', and 'skip'. > > I would like to see the same buttons in the sx editor along with a > choice of seeing sx for each account on separate tabs. > > And of course I will work on this myself (with helpful comments from > developers). > > Thoughts? Feasible? Sure. I separated out much of the application logic from the UI in the last go-round in order to support things like this; see src/app-utils/gnc-sx-instance-model.{c,h} in particular. Why is a split-pane in the Account tab better than the existing since-last-run (SLR) dialog (or maybe moving that dialog into a tab)? Do you really need to see both things at once (a main motivation for a split-pane)? Otherwise, I fear the page wouldn't be big enough to see either. What's the benefit of splitting up the upcoming transactions across separate tabs (by account)? Instead, maybe, allowing an Account-based filter on the existing SLR page? One thing that people regularly ask for is – in the editor for a particular SX – to see the upcoming instances, so that they may quickly schedule something forthcoming. This should be pretty easy to do, by simply generating the instance model through some configurable date in the future (30 days? 60 days? drop down? as a function of the frequency of the SX?). Unfortunately, there doesn't seem to be a way to just generate the instance model for a single SX, but that should be straightforward to add in. Anyways, I'm happy to help, but my response time might not be very low. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpgrkS8Sq1eJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions
On Wed, Oct 15, 2008 at 5:25 AM, Tom Browder <[EMAIL PROTECTED]> wrote: > I would like to see the scheduled transactions (sx) capability > enhanced (see enhancement bug # 521285) to be more like Quicken. I > would like to see a split-pane in the account window showing due and > buttons to push like 'enter', 'edit', and 'skip'. > > I would like to see the same buttons in the sx editor along with a > choice of seeing sx for each account on separate tabs. > > And of course I will work on this myself (with helpful comments from > developers). > > Thoughts? Feasible? > Congratulations on taking this up! I don't know anything about the sx code, but judging by the bug reports this is an area ripe for attention. (I believe at least some of those bug reports are actually underlying register problems, which I am working on.) Anyway, I think Josh Sled is the scheduled transactions expert, so he may be able to help you. -Charles > -Tom > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Scheduled Transactions
I would like to see the scheduled transactions (sx) capability enhanced (see enhancement bug # 521285) to be more like Quicken. I would like to see a split-pane in the account window showing due and buttons to push like 'enter', 'edit', and 'skip'. I would like to see the same buttons in the sx editor along with a choice of seeing sx for each account on separate tabs. And of course I will work on this myself (with helpful comments from developers). Thoughts? Feasible? -Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel