I am using GnuCash 4.0 for Windows. When entering transactions with Cyrillic characters (Ukrainian, the same issue with Russian), after I type first letter and there is a match, Quickfill correctly fills the string starting with the same first letter. However, when I continue typing, each new character is treated as the first character again, so the whole string is again replaced with a new string starting with a second character (and third, fourth etc.). It prevents me from entering a transaction starting with the same letter as any previously entered transactions (but different from that one). Steps to reproduce: 1. Enter 3 transactions into a new account, starting with different Cyrillic characters (e.g. Один, Два, Три) 2. Type a new transaction with letters matching first characters of previous transactions (ОДТ) The Quick-filled transaction name switches between previously entered transactions: (firstly Один, secondly Два, thirdly Три). As a workaround, I can type space and then the new transaction name - it seems to prevent the Quickfill. Alternatively, I can remove some characters from the autofilled string using backspace key and replace them with new characters, however sometimes this seem to trigger Quickfill and with some strings the whole program crashes.
Same with Hebrew.
I see exactly the same behaviuor under Fedora 32 Linux using UTF-8 Cyrillic codeset at least. While I'm trying to type using ASCII (1-byte) letters everything seems to be ok.
Fixed for 4.1, thanks for the report.
*** Bug 797866 has been marked as a duplicate of this bug. ***
I have similar issues with German Umlauts (ä,ö,ü) in Version 4.0+ (Arch Linux)
(In reply to thfrdue from comment #5) > I have similar issues with German Umlauts (ä,ö,ü) in Version 4.0+ (Arch > Linux) We'll be releasing GnuCash 4.1 this weekend and the Arch packager is usually pretty quick to make releases available. If you're in a hurry you can install a nightly flatpak from https://code.gnucash.org/builds/flatpak.
Still broken in 4.1 for Hebrew.
May be relevant that Hebrew is RTL. I'm on Windows.
The fix for bug 797839 seems to fix this too, subject to my (in)ability to type on the Hebrew keyboard.
(In reply to John Ralls from comment #6) > (In reply to thfrdue from comment #5) > > I have similar issues with German Umlauts (ä,ö,ü) in Version 4.0+ (Arch > > Linux) > > We'll be releasing GnuCash 4.1 this weekend and the Arch packager is usually > pretty quick to make releases available. If you're in a hurry you can > install a nightly flatpak from https://code.gnucash.org/builds/flatpak. Thank you for good job! The bug is definitely fixed in 4.1 at least for usual "left-to-right" languages. Alexey.
Oddly the fix I committed today doesn't have anything to do with RTL or LTR, it was that the delete handler was passing the wrong character count, creating corrupted UTF8 characters. It should have affected Cyrillic the same as Hebrew and I'm a little puzzled why it didn't.
The issue is not resolved for me with GnuCash 4.1 for Ukrainian input language either. Now the program crashes when I continue typing (after finding a match). Attaching a tracefile (hopefully this can help).
Created attachment 373831 [details] Tracefile after QuickFill crash
Comment on attachment 373831 [details] Tracefile after QuickFill crash This is a trace file, no stack trace. Please read wiki.gnucash.org/wiki/Stack_Trace
Frank, this is a Windows bug. Creating a stack trace on Windows isn't possible for users who aren't also programmers. For Maryan: Before you do anything else please install and test with a recent nightly build (4 August or later) from https://code.gnucash.org/builds/win32/maint. If that fixes it, great, please say so and no need to continue troubleshooting. (voldermort, we're still waiting for you to do the same, both here and on bug 797839). What you attached is not a trace file, either. It's a log file, which isn't useful at all and had it not been empty would have published details of one or more of your transactions to the world, something most people would prefer to avoid. Please see https://wiki.gnucash.org/wiki/Tracefile for instructions on finding the tracefile that went with your crashed session. Unfortunately we don't have a Ukrainian template for me to try to reproduce the crash on my Windows VM. Maryan, can you make me a simple one, making sure that you can crash GnuCash when entering an account? Windows has two keyboards, Russian(Ukraine) and Ukrainian. Which one are you using?
My bad, I have attached a wrong file. After downloading and installing the latest nightly build (gnucash-4.1-2020-08-15-git-4.1-50-gc5e5bdf8c+.setup.exe) I can confirm the issue is gone! I can type any string, and it is no longer locked to the first match. Unfortunately, I can still see some crashes with this version (please see attached my new try of a trace file :)). That might be not related to the Quickfill, as the issue seems to happen after I remove a transaction (by clicking on it and then clicking on Delete button).
Created attachment 373832 [details] Trace file
@John (In reply to John Ralls from comment #15) > Windows has two keyboards, Russian(Ukraine) and Ukrainian. Which one are you > using? I am using Ukrainian (Ukraine). Thanks for the help!
(In reply to Maryan from comment #16) > Unfortunately, I can still see some crashes with this version (please see > attached my new try of a trace file :)). That might be not related to the > Quickfill, as the issue seems to happen after I remove a transaction (by > clicking on it and then clicking on Delete button). Does GnuCash actually crash, meaning that the window disappears, possibly replaced by a Windows message box saying that it quit unexpectedly? Otherwise those errors aren't surprising (proc is a Linux thing) and are just a symptom of sloppy programming.
There is no Windows message box, GnuCash freezes for 2-3 seconds and then its window disappears.
I have checked a template attached to a linked bug (Bug 797839 - Auto-complete prevents entering non-ASCII transaction descriptions), and was able to reproduce the same crash simply by opening Checking Account, clicking on one of the past transactions and clicking Delete button. This seems to be a (newly introduced?) bug in the version I have (gnucash-4.1-2020-08-15-git-4.1-50-gc5e5bdf8c+.setup.exe).
Sorry for the delay getting back to this. Chris Lam fixed that crash on August 16 in https://github.com/Gnucash/gnucash/commit/00efc1696a8c8521cda8791f113ae83cf58240f8. Please check again with a more recent build. It is indeed completely unrelated to this bug. Since we haven't heard from voldermort I'm going to assume this is fixed.
@John Everything works fine for me in version 4.2. Thanks a lot!
