GNOME Bugzilla – Bug 720555
General Ledger - Can't Enter Transaction Amounts
Last modified: 2018-06-29 23:22:37 UTC
See thread in the -dev archives starting December 2 2013 with this same title 'General Ledger - Can't Enter Transaction Amounts'. This refers to attempting to create a new transaction in the blank transaction area at the bottom of the General Ledger view. Apparently this is an issue in all operating systems starting with release 2.5.8 and continuing with release 2.5.9 and 2.5.10. Today I observed it in release 2.5.10 December 15 nightly windows build marked git rev f70e0ee+ on 2013-12-15. I can create a transaction in the blank transaction area of the ledger view but I cannot change or enter values until after I have used the enter key to accept the partial transaction and it has moved out of the new transaction area at the bottom of the window. Curiously, If the transaction is populated by the type-ahead feature, I can then change amount values in the new transaction area of the General Ledger view, but if I fill in accounts manually in the new transaction area then press enter and the transaction moves into the existing transaction area, I still cannot enter amounts while in the general ledger. I need to jump to one of the account registers from the ledger register before I can enter an amount. If I try to enter an amount in the ledger view but Jump without cancelling or accepting the failed edit, then I cannot edit from the other side because GnuCash thinks I have a pending edit elsewhere. In today's test of release 2.5.10 I was able to accept the new transaction in the general ledger but the curser highlight did not follow the created transaction so I had to search for it to complete the amount edits.
I'm not able to replicate this. I enter a date, tab to a description, type that. The next tab takes me to the Action field of the first split. I keep tabbing to account, enter one, tab to the amount field (Funds in or Funds out, depending), enter a value; next tab goes to a new split, repeat, balancing the amount and in the opposite field. That's the way it's supposed to work. What *exactly* are you trying to do?
In the December 15 build mentioned above I use Tools > General Ledger to open a new General Ledger View. Then I click in the blank new transaction box at the bottom. I tab to the description field and enter a few characters until the autocomplete feature starts filling things in from some existing history. Then I tab through the split line(s) to the amount box, enter a different value, tab on and the value I just changed goes back to the value that the autocomplete feature had entered. It is possible to edit the memos and those edits appear to stick. I have to 'Accept' the transaction, then hunt for it so that I can change the amounts. If I am careful to avoid triggering the Autocomplete feature I can tab along, entering text in the various boxes until I get to an amount box for the first split line. I enter an amount. Then when I tab to the second split line, the amount disappears. Now, if I tab to the empty line at the bottom before accepting, the curser seems to follow the new transaction so that I do not need to search for it. Then I can go back to the empty amount boxes and enter values. Since the first value disappeared, no balancing amount appears either.
I got ahead of myself. After accepting the non-autocompleted transaction with no values the transaction moves to today's date in the sort sequence and the curser goes with it. Staying in the General Ledger, if I tab into an amount box, enter a value, then tab to the next split line, the value again disappears. The second amount also disappears after I try to enter it. At that point I thought that I had failed to edit the transaction so I 'jumped' to one of the account registers. Then I could start entering values until I tried to accept the transaction, which triggered the 'Already being edited in another register' message. If I go back to the General ledger and "Save", the values are still missing. This is definitely not how it is supposed to work, and it is not how it works in single register windows. The only thing I am not sure about is whether this has ever worked in previous versions, since I normally do not try to do edits in the general ledger register.
The only way I can get it do that is to create a split without an account, and then only sometimes. Then when I tab through the account goes to Imbalance-USD and the amount goes blank. Obviously not an issue when editing an autofilled split. The "sometimes" are if it's the first split, or if I change the amount in the auto-balance split. If I clear the account on an autofilled split, it gets put back when I tab through. Tabbing won't let me out of the last split until I put in an account. That's on Win7 and OSX. I'm firing up an XP VM, but it's been a while since I used XP so it's going to take a while to do its updates before I'll be able to use it.
I do have a couple of other programs on that XP 32 bit VM, including Git, Java 7 and Servio. I do not have a tracefile set up yet. It seems odd that XP would differ for GnuCash. I think it runs a little slow, I just checked it only has 1 gig of virtual RAM. It does not seem to have any other signs of resource starvation.
Bumping the RAM up to 2 gig made no noticeable difference to this XP VM. I also noticed that the filter issue with the General ledger that I reported in that other bug today is the same in both Releases 2.4.13 and 2.5.10, so it probably is not related to this bug. The test file is about 3,400 KB compressed. I will do the trace tomorrow.
> It seems odd that XP would differ for GnuCash. It does seem odd, but I *can* reproduce the problem on XP. Figuring this out isn't going to be fun.
Reviewing the original notes, I see that Ted was using Vista when he saw the problem. I currently cannot use Vista because my old laptop needs a new cooling fan. In your first note you said that you saw something on OSX in the 2.5.9 build, I presume. I am thinking out loud, hoping that I will trigger some ideas of where to search. There have obviously been substantial changes between Vista, XP, 7 and (ugh)8, but I imagine that your compiler creates code for the lowest common denominator, so to speak.
Created attachment 264420 [details] Last session trace Trace from last session. There are a couple of significant entries, But I do not remember my exact sequence of actions to trigger them. I suppose the installer may select different chunks of code depending on the target OS. This is in Windows XP.
Nothing in GnuCash is that sophisticated about M$Win version. We compile in a unix-like environment called MinGW using GCC on an XP machine. Those trace warnings may indeed be useful clues. I'm particularly perturbed about the gnc_numeric errors.
Another question is why has this only been seen in the General Ledger but not in single account registers?
Created attachment 264428 [details] Search box error trace For this session I opened the file, went to the Accounts window and searched for some text. While in the results window I started to create a new transaction. I entered random text and tabbed along to the first split account and added a real account. I tabbed to the first amount box, entered a value and tabbed on to the next split line. The amount disappeared. After tabbing into the account field of the second split line and entering another valid account I tabbed to the amount and added a value. Then I tabbed to the third line and the second value also disappeared. I pressed Enter and the transaction disappeared because the search text was not in this new transaction. I went to one of the real accounts, found the transaction and I was able to enter values there and save the transaction with an imbalance amount as expected for that particular edit. I also tested the 'with subaccounts' register view and found no error there.
There is one more detail that may be significant. When the newly created transaction (which for all these tests had the default 'Today' date) is accepted, the curser actually lands on the next transaction after the newly created transaction in the date sorted list.
(In reply to comment #4) > The only way I can get it do that is to create a split without an account, and > then only sometimes. Turns out that's wrong, and the whole WinXP thing was a red herring. I was using a book with trading accounts enabled on OSX and Win7, a path difference I discovered when stepping through the split save operation in parallel on both XP and OSX. When I switched the account in OSX to one that doesn't use trading accounts, it fails the same as on XP. As for why it fails in General Ledger and not in a regular account, it's because that bit of code assumes that there's a default account for the open register, a condition that a General Ledger register doesn't meet.
I don't know about red herring, but I really like pickled herring, especially during the holiday season. That should mean a smaller haystack to search for the needle while I am mixing metaphors. Since the same thing happens in other search result windows there are more ways to set up the problem too. I wonder if the problem started in release 2.5.8 or earlier. Maybe a bit of 'old' code got separated out with the register 2 code. I appreciate the effort you are putting toward solving this issue.
I found that release 2.5.6 git rev 1cfa866+ on 2013-10-29 does not have the problem in the Since Last Run results window butgnucash-2.5.7-2013-11-15-git-8d50e55+-setup.exe does exhibit the problem in the Since Last Run results window.
What problem in the Since Last Run window? What's that got to do with this? r23584 fixes this bug, at least for me. Please try tomorrow's nightly.
OK I was searching for the first build with this problem unable to enter amounts in general ledger view and other search results views including the since last run results view. I narrowed it down to first appearing in the November 7 Windows Nightly build of release 2.5.7. However, since you have fixed it now, that does not matter.
> However, since you have fixed it now, that does not matter. We'll decide that after you try tomorrow's nightly. ;-)
> I narrowed it down to first appearing in the November 7 Windows Nightly build > of release 2.5.7. Interesting. That would be http://svn.gnucash.org/trac/changeset/23384/gnucash/trunk/src, which is the same change I just made, about 60 lines earlier in the same function.
I tested the December 20 build in Windows XP and found that the amounts could be edited as expected in the Since Last Run results view, and in the General Ledger View. When the transaction is accepted, the curser now lands on the newly created transaction in the register. I thought that I reported this earlier today, but I guess it did not go out onto the internet.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=720555. Please update any external references or bookmarks.