GNOME Bugzilla – Bug 347474
Register: Tab goes to wrong split
Last modified: 2018-06-29 21:09:36 UTC
While entering a transaction with multiple splits, I tab through the fields. After the second split, tabbing brings me back to the first split and not to the third. I have gnucash 2.0.0 on Slackware 10.0, linux version 2.6.15. The register is set to "Auto-split" in preferences. Steps: 1. Open an account register. 2. Enter a description 3. Tab through the fields to the amount. Enter it. 4. Tab until you reach the account field of the second split. Choose an account. Tab to the amount. Enter one. 5. Hit tab twice more. 6. Observe that you are now editting the first split again rather than the third one as expected.
Happens to me too. I haven't yet checked whether or not this only occurs when all of the entries balance so far, so that there is no residual amount to account for. The behaviour in 1.8.x was not like this.
Correction to previous comment: this occurs whether or not the entries balance so far, as long as it is a new entry in the General Ledger (haven't checked other entry methods).
I have not been using the General Ledger. I open the register for the asset/liability account from which payment is to be made. I have upgraded to 2.0.1 and still observe this behaviour. I have noticed that whenever there is another split below the current one, it will correctly tab to that split. For example, when a blank split is below the current one, you can tab to it. However, when you are on the very last split, tabbing to the "next" split arrives at the first split rather than creating a new one. I have been pressing the up arrow to go up one split (this creates a new one at the bottom with the remaining imbalance) and then down arrow twice to get to the new split.
*** Bug 360557 has been marked as a duplicate of this bug. ***
*** Bug 375035 has been marked as a duplicate of this bug. ***
*** Bug 380386 has been marked as a duplicate of this bug. ***
I have built trunk svn 15187 and it still occurs with this version. This one is on a system using gtk+ 2.8.20. It also occurs on a system with gtk+ 2.10.6 and gnucash 2.0.1. I had thought that trying it with a newer gtk might have an effect, but it didn't. Gnucash 2.0.1 was rebuilt after the upgrade.
It happens to me too. I can add that this new behaviour was introduced late in the 1.9.something or 2.0 rc series, it was not present from the beginning of the gtk 2 implementation.
When I'm entering a split transaction in an account window (not general ledger) with gnucash 2.0.2, and I hit tab on the last split, I move back to the date field of the transaction instead of moving to the next split line. This is exceedingly annoying. This bug is almost six months old, sort of amazing that no developer has done anything with it in six months.
I have upgraded to gnucash 2.0.4. It still has this bug.
*** Bug 388931 has been marked as a duplicate of this bug. ***
*** Bug 469041 has been marked as a duplicate of this bug. ***
*** Bug 507142 has been marked as a duplicate of this bug. ***
Please check out the attached patch and test it thoroughly. The register can a beast, so really stress test it :-)
Created attachment 108196 [details] [review] First try
Applied as r17078 and marked for backport to branches/2.2. This is still open for comments and needs regression tests :-)
I haven't tested thoroughly, but it looks good initially. I'm really happy that this one might be fixed! Thanks. I'll report again after I've used current trunk for several days.
26-13 == 13 > 7, cool :-) Applied to branches/2.2 as r17137 for GnuCash 2.2.5. Thanks for the patience.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=347474. Please update any external references or bookmarks.