The Type-ahead feature added for GnuCash 4.0 has an issue with initialization, raised in https://lists.gnucash.org/pipermail/gnucash-user/2021-April/096147.html and following. Specifically: upon first start of GnuCash, the first transaction entered in a register hangs after the user enters the first character in the Transfer column. The combo box indicator shows, but there is no further indication that anything has happened; the machine just stops. The application doesn't respond to keyboard input, but clicking elsewhere in the register window causes the Create account dialog to display (with the first character entered displayed as the account name to create). Cancelling this dialog then brings focus back to the Transfer column, the Accounts combo box shows, and all behaves as expected. From this point forward, Type Ahead seems to work as expected. Numerous users noted workarounds to the problem, including: pre-selecting the combo box before invoking Type Ahead; Tab-Shift Tab key sequences; and the above Create/Cancel new account dialog.
I think this bug is for me as I wrote the look-ahead feature. I hope I can repro this on my machine. Will keep you posted.
I'm trying to repro this problem, but I'm not able to with the version I'm currently using (4.4). I'm trying to follow your steps: - Start GC - Click on one of the account - Go to the bottom and enter a new transaction - Click in the transfer column, enter one character In my case, the combo box immediately appears. So there must be something that's different either with your GC accounts or with your system. 1) Am I following the steps right? 2) Can you tell me which GC version you're using? 3) Does the problem occur no matter which character you enter? If I'm not able to repro, debugging is going to be painful :( Jean
I've experienced this as well, though my scenario might be a tiny bit different. I seen to always get it when i tab through the transaction details and do everything via keyboard. For me, it seems to happen about 1 out of 20 times I enter a completely new transaction, but I've never been able to identify a pattern that makes the two behaviors different. I have found similar to David that I can do a shift tab, then tab for it to work correctly again.
Gnucash 4.4 Build ID: 4.4+(2020-12-28). Jean, the problem is keyboard-driven, as Matt notes. It occurs on the first transaction in a fresh register. To reproduce: 1) Open GnuCash. 2) Open a register. 3) Tab to the description and enter a new transaction ("sxkjh"). 4) *Tab* to the transfer field. 5) Type a letter-- the register hangs. A couple of interesting points: * The problem happens in all View modes, and when Double line view is active. * The Menus and Toolbar remain active, so I can click Cancel, for example, which clears the transaction out, and then the register behaves properly. * The problem, once cleared, does not return for a register while the register remains open. * The problem returns when you reopen the same register in the same session.
Hi David, I try and try again following your steps meticulously, but it does not happen for me. I'm on Windows 10, in case that could make a difference. Could you try running in debug mode: "C:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug --extra Make sure there's a /tmp/ folder on your machine. When in debug mode, after quitting GC, you should be able to find a file named like this: /tmp/gnucash.trace.ZZUD20.log Perhaps it has some info on what's going on... In case you're curious the debugging options are described here: https://wiki.gnucash.org/wiki/Logging Jean
As David knows well the wiki page you want is https://wiki.gnucash.org/wiki/Tracefile. Only Windows uses mkstemp, Unix variants all over write it and the location where it ends up depends on the OS; all that's documented in the Tracefile wiki page.
I have the exact same problem with: GNUCash version: 4.5+(2021-03-27)on Manjaro Linux (5.10.32-1-MANJARO) with MATE DE (1.24.1) I haven't found anything in the logs - please see https://lists.gnucash.org/pipermail/gnucash-user/2021-May/096428.html Sebastian
@Sebastian I wonder if adding --extra to the command line would output more info in your case. Since I'm not able to repro the issue, I think the only way forward is for me to add more debug info in the code, to try to pinpoint where the hangup occurs. If somebody has a better idea, I'm all ears.
David is this from a completely new datafile? There's a recent bugfix about the Transfer dropdown list being empty.
Chris, on first call, there is no dropdown. It is not empty; it simply does not appear. Neither does the triangle button, I'll note.
@Jean, the --extra didn't output more info. @Christopher, I can confirm Davids comment: there is no drop down.
I've had a chance to fire up a test and check for a trace file. Unfortunately, the trace file is 0 bytes when I trigger this problem. For the record, I created a new XML data file with a fully empty basic account structure, saved as "test," and then restarted Gnucash. This opened the test file in a new session. When I opened the checking register, I created a new transaction for an opening balance (description: "open") tabbed to the transfer column, and typed "f," which caused my problem (I was shooting for the "Expenses:Auto:Fuel" account). I then Canceled the transaction and exited GC. The tracefile was empty. I'll attach my test file, just for completness.
Created attachment 374058 [details] Empty File for test
Created attachment 374059 [details] screenshot screenshot from trying comment 12 -- note I use bleeding edge; my build id is Build ID: git 4.5-159-ga60471c95+(2021-05-01) on win10
Created attachment 374060 [details] My Experience is Different In reply to Comment #14: So, on your machine you get a dropdown. On mine, I don't, as evidenced on this screenshot. What now?
(In reply to David from comment #15) > In reply to Comment #14: So, on your machine you get a dropdown. On mine, I > don't, as evidenced on this screenshot. What now? The silly question is which build you're running?
Created attachment 374061 [details] Zip file of libgnc-register-gnome.dll (In reply to David from comment #12) > I've had a chance to fire up a test and check for a trace file. > Unfortunately, the trace file is 0 bytes when I trigger this problem. > Was it really 0 bytes, that would imply the wrong file. From a command prompt, I started gnucash with this... "c:\Program Files (x86)\gnucash\bin\gnucash.exe" --debug and the gnucash.trace.XYZ.log file is 62K located in... ..\Users\xxx\AppData\local\Temp Did you notice the button is pointing 'UP' and from what I can tell it is set as part of the show popup routine. You might like to try this. I have created a new .dll file that will output the popup height size to the log file. Save the existing one from gnucash\bin, copy in my one and run gnucash as above. Now search the trace file for 'Test' and add details here. This is really trying to identify if there is size to the popup and where it was going to be popped. After you are done you can replace .dll file with the saved version.
If Bob's dll does not do the trick, I believe the next step is to put trace information in the code to see where things hang (debug messages), but I'm having a hard time getting my machine to the point where I can compile again. If someone is able to do it, that will speed things up. We would create a verbose version of the app, which you guys could test on your machine. If all goes well, we'll have more indication of what's happening. Or, if this happening to someone who knows and is able to run a debugger on the app, that would also be a solution Jean
@Chris, Comment #16: see Comment #4 @Bob, Comment #17: Yes, gnucash.trace was zero bytes. Repeatedly. Today, however, I copied your dll and got a more substantial file, which I will attach shortly.
Created attachment 374062 [details] Trace file using special dll
David, Thanks for doing that, from your previous screen shot the Gnucash window was about 970 wide and 350 high, I am assuming that to still be the case, if not please do another run and add log and corresponding screen shot. I get these log entries for your test... [gnc_item_edit_show_popup] Test, popup_h is 138, popup_w is 555 [gnc_item_edit_show_popup] Test, popup_x is 431, popup_y is 24 From your log file the popup was [gnc_item_edit_show_popup] Test, popup_h is 138, popup_w is 541 [gnc_item_edit_show_popup] Test, popup_x is 1159, popup_y is 48 The interesting thing I think is the popup_x position which seems to imply it is off the screen, may be wrong will need to have a think. As an experiment, can you follow your procedure and at step 5 press the f key and then immediately use the 'enter' key, does the transfer field populate?
Hi. Pressing the f key and then enter has no response, no matter how many times I hit it, or how long I wait. However, pressing tab 3 times immediately after the f key does populate the transfer field with Expenses:Auto:Fees. For humor, I tried maximizing my application window to see if the box would appear then. No dice.
Additional random tests: Thinking maybe the size of the transfer field might affect the drop down, I increased the transfer field width dramatically. No change in behavior. Wondering whether the key buffer might get processed anyway, I tried typing "fu" (for "Fuel"-- really!) followed by the magical three tabs, but it gave me Expenses:Auto:Fees again. So it seems to get stuck after the first character gets entered. For the record, my screen is set to 1980x1080 at 125% sizing. I tried using 100% sizing, but that didn't change things.
Created attachment 374063 [details] Zip file of libgnc-register-gnome.dll David, I have added some additional values to be added to the trace file, can you give it a spin as before and add an updated screen shot to reflect new layout. Still trying to identify relevant parts of source, shame I can not reproduce.
This seems related to bug 798061.
Created attachment 374064 [details] Trace file with newer dll Bob, this is the trace file using your dll from last comment. I see that the screen dimensions reflect the full screen now. I'll leave the earlier trace active for reference.
Do you remember the days when this type of problem would automatically be chalked up to 'compiler error'?
Created attachment 374067 [details] Zip file of libgnc-register-gnome.dll David, another zipped up dll file adding more information to the trace file. Can you give it a spin and trace file will have the count of entries, so if you enter f there should be 6 and then u it should have 1. Still trying to identify if it is a display issue or a list issue.
I experience similar behavior (autocompletion hanging), and found a "workaround". I hope sharing this will help some using GC, or maybe even tracing the bug. Assuming I have such an expense created: "Expenses/Common/Groceries" I used to start typing "gr" and it would show up. Now it hangs similarly to what was described above. However if I type "ex/co/gr" the "Transfer" column gets populates as I expect and the selection box shows up and reacts properly.
It appears that Maciej is using a forward slash as the account separator character instead of the default colon. I wonder if this makes a difference.
(In reply to Maciej from comment #29) > I experience similar behavior (autocompletion hanging), and found a > "workaround". I hope sharing this will help some using GC, or maybe even > tracing the bug. > > Assuming I have such an expense created: "Expenses/Common/Groceries" > I used to start typing "gr" and it would show up. Now it hangs similarly to > what was described above. > However if I type "ex/co/gr" the "Transfer" column gets populates as I > expect and the selection box shows up and reacts properly. Thanks for the input. What you are describing is actually how this field originally behaved, and users complained that they couldn't just type "groc" to pull up the Expenses:Common:Groceries account directly. Jean provided a new account field processor to allow the direct method, which is what we're trying to get fixed. Your comment, combined with comment #30 from David Carlson, however, got me wondering, and I believe I *do* have a new data point. David's thought that the separator makes a difference is not, I believe, correct. I have now tested a number of different ways, and I have found that if I start with a character that is at the head of an account hierarchy, the drop down appears, and all is fine. So, beginning with A, E, I, or L (for Assets, Equity, Expenses, Income, or Liabilities), things go fine. Any *other* letter, however, causes the odd behavior. Moreover, if I add a new top level account, like "Xtra Account," I can now type "x" and things will work for that letter. Deleting this account restores the broken behavior. So it would appear that if the first character typed is not one that begins a top level account, the error will occur.
Over in bug 798061 user Benjamin Gordon discovered that it reproduces reliably in Fedora 34. I found that to be the case with an F34 VM I'd set up recently, and I found another way to unfreeze the control: Click the combo box reveal arrow twice. Please see if that unsticks it for you.
Clicking the arrow just once works better because it doesn't make a selection. The popup doesn't display but you can continue typing. Best results if you type the first letter and click the arrow, then continue typing. Bob, I've debugged a bit and the signal from gtk_window_propagate_key_event isn't getting handled. Changing the condition in popup_set_focus (combo cell-gnome.c:942) doesn't make the list appear at first but it does allow the second keystroke's signal through after which the popup does appear.
Eh, that's changing the condition to `if (0)`...
So following up on that, after the 'f' in popup_get_width, the alloc filled in by gtk_widget_get_allocation is gdb) p alloc $10 = {x = -1, y = -1, width = 1, height = 1} The number of entries after 'f' is 6 and after 'u' is 1 (if, that is, you've clicked the arrow to release the grab); the alloc after processing the 'u' is $22 = {x = 0, y = 0, width = 581, height = 150} After clearing and trying again (and as already noted it only fails the first time after opening a register) the alloc from gtk_widget_get_allocation after 'f' is $26 = {x = 0, y = 0, width = 581, height = 352} I thought at first that that must not have anything to do with it because the alloc filled in popup_get_width is {-1, -1, 1, 1} when one enters the initial of one of the top-level accounts (i.e. a, e, or l). But that branch of code displays the whole account list. There must be something about the way we're initializing the restricted account list that it isn't ready. Out of time for today.
I think I may of found this one unless I have found a different bug. If navigating by the keyboard and you tab to the transfer cell and then type a letter, we get to gnc_item_edit_show_popup and starts to create and hopefully show the popup list. All this is fine and at line 1084 the arrow is set to UP. But what I have noticed is that on first use when the cell height is obtained by gnc_item_list_get_cell_height it is 1 pixel less than required. This should be corrected by the check_popup_height_is_true function which calls gnc_item_edit_update via an idle function. This all works for when the toggle button is clicked but from the keyboard it does not as on line 268 there is a test for item_edit->show_popup being set but that only gets set in the gnc_item_edit_popup_toggled call back. So I can fix this by adding item_edit->show_popup = TRUE; on the line after setting the arrow direction, 1084. John, can you try that.
Bob, It works in that the list box displays with 6 accounts whose full names contain 'f'. But the next keystroke is weird: The 'f' is lost and it lists all of the accounts whose full names have the second character. The third character typed then searches the whole string again. For example if I type f-u-e I get the 6 accounts with 'f' in them, then the 29 having a 'u', then with the 3rd keystroke Expenses:Auto:Fuel.
OK, more digging...
OK after some more testing, I think the cause of your trouble was that the transfer cell was being updated too early, it should of been showing 'f' 6 accounts, 'fu' 1 account, 'fue' 1 account, 'fuel' 1 account. Tabbing when the account list has one entry or clicking on the account list would then fill in the cell. This I believe is down to the gnc_item_list_select at line 682 of combocell-gnome.c. If I change those lines to... if (!gnc_item_list_using_temp (box->item_list)) { block_list_signals (cell); gnc_item_list_select (box->item_list, match_str); unblock_list_signals (cell); } it seems to work. That gnc_item_list is used when navigating using the 'Ex:Au:Fu' so wrapping it with the if still allows it to work for quickfill.
That does indeed work and it mirrors the same condition up top so it makes sense. I think that argues for a little refactoring to make it clearer what's going on. Do feel like doing it?
Bob has done the refactoring and merged the results; will be in GnuCash 4.6.
