Auto fill not working correctly (only match the first char you type ...) 1. Open a register 2. Type first letter into the description field ,the suggested string appended at the end of the first letter. 3. Type second letter, the appended string at step 2 didn't change and autofill cannot best match the second letter anymore.
*** Bug 796776 has been marked as a duplicate of this bug. ***
This is the same as bug 796734, but is the first report on Windows. You're obviously not going to be able to disable the IME as a workaround either.
(In reply to John Ralls from comment #2) > This is the same as bug 796734, but is the first report on Windows. You're > obviously not going to be able to disable the IME as a workaround either. Yup, I am using Chinese IME, It is not very practical since I need to type Chinese all the time ...
I fixed this for MacOS and I think that the way I did it will work for Windows too. Please test https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-11-git-3.2-263-g48b29f5e9+.setup.exe.
(In reply to John Ralls from comment #4) > I fixed this for MacOS and I think that the way I did it will work for > Windows too. Please test > https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-11-git-3.2- > 263-g48b29f5e9+.setup.exe. Tested in windows, the problem is still here, Autofill only match with the first letter you type and cannot match the second letter.
Created attachment 372977 [details] Screenshot showing quickfill of chinese characters with selection. I'm not able to reproduce this with https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-17-git-3.2-276-g83b1b8adf+.setup.exe. Are you typing in Roman letters or Chinese? If in Chinese, what roman letter sequence are you typing to produce the characters, at what point does the quickfill recognize and fill in, and is there any selection at that point? For example, to create the attached illustration I typed faso3noshi4hanguo3 (utter nonsense, I'm sure, as I don't know any Chinese) in the first transaction. Quickfill recognized and provided the proposed completion after typing faso3noshi4. The numbers in parentheses are the selections from the pick list.
(In reply to John Ralls from comment #6) > Created attachment 372977 [details] > Screenshot showing quickfill of chinese characters with selection. > > I'm not able to reproduce this with > https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-17-git-3.2- > 276-g83b1b8adf+.setup.exe. > > Are you typing in Roman letters or Chinese? If in Chinese, what roman letter > sequence are you typing to produce the characters, at what point does the > quickfill recognize and fill in, and is there any selection at that point? > > For example, to create the attached illustration I typed faso3noshi4hanguo3 > (utter nonsense, I'm sure, as I don't know any Chinese) in the first > transaction. Quickfill recognized and provided the proposed completion after > typing faso3noshi4. The numbers in parentheses are the selections from the > pick list. Install the lastest nightly build, test procedure as below: 1. There are some existing transaction with description that begin with "2017" and "2018" 2. Open a new transaction , type the letter 2017 3. Autofill happened when I type the first letter '2' (see attachment) 4. when I type more letter '017' , the autofill stay the same and cannot best match with the "2017"
Created attachment 372978 [details] Autofill cannot best match after the first letter
(In reply to Alex Mak from comment #7) > (In reply to John Ralls from comment #6) > > Created attachment 372977 [details] > > Screenshot showing quickfill of chinese characters with selection. > > > > I'm not able to reproduce this with > > https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-17-git-3.2- > > 276-g83b1b8adf+.setup.exe. > > > > Are you typing in Roman letters or Chinese? If in Chinese, what roman letter > > sequence are you typing to produce the characters, at what point does the > > quickfill recognize and fill in, and is there any selection at that point? > > > > For example, to create the attached illustration I typed faso3noshi4hanguo3 > > (utter nonsense, I'm sure, as I don't know any Chinese) in the first > > transaction. Quickfill recognized and provided the proposed completion after > > typing faso3noshi4. The numbers in parentheses are the selections from the > > pick list. > > Install the lastest nightly build, test procedure as below: > 1. There are some existing transaction with description that begin with > "2017" and "2018" > 2. Open a new transaction , type the letter 2017 > 3. Autofill happened when I type the first letter '2' (see attachment) > 4. when I type more letter '017' , the autofill stay the same and cannot > best match with the "2017" Seem the autofill can only match with the first letter ...
(In reply to Alex Mak from comment #9) > (In reply to Alex Mak from comment #7) > > (In reply to John Ralls from comment #6) > > > Created attachment 372977 [details] > > > Screenshot showing quickfill of chinese characters with selection. > > > > > > I'm not able to reproduce this with > > > https://code.gnucash.org/builds/win32/maint/gnucash-3.2-2018-09-17-git-3.2- > > > 276-g83b1b8adf+.setup.exe. > > > > > > Are you typing in Roman letters or Chinese? If in Chinese, what roman letter > > > sequence are you typing to produce the characters, at what point does the > > > quickfill recognize and fill in, and is there any selection at that point? > > > > > > For example, to create the attached illustration I typed faso3noshi4hanguo3 > > > (utter nonsense, I'm sure, as I don't know any Chinese) in the first > > > transaction. Quickfill recognized and provided the proposed completion after > > > typing faso3noshi4. The numbers in parentheses are the selections from the > > > pick list. > > > > Install the lastest nightly build, test procedure as below: > > 1. There are some existing transaction with description that begin with > > "2017" and "2018" > > 2. Open a new transaction , type the letter 2017 > > 3. Autofill happened when I type the first letter '2' (see attachment) > > 4. when I type more letter '017' , the autofill stay the same and cannot > > best match with the "2017" > > Seem the autofill can only match with the first letter ... The suggested string should be refresh/update when i type the 2nd letter '0' , however, seem it cannot update dynamically with the typing.
Hmm. It works correctly for me, but that's with pinyin/simplified, not traditional. I'll try again tomorrow with traditional.
(In reply to John Ralls from comment #11) > Hmm. It works correctly for me, but that's with pinyin/simplified, not > traditional. I'll try again tomorrow with traditional. Yup, u r right. This is traditional chinese IME (Cangjie / Quick).
The Chinese (Traditional Hong Kong SAR) IME does indeed show the problem.
Created attachment 372980 [details] Pinyin (Chinese mode)
Created attachment 372981 [details] Pinyin English mode
Some testing is done for different IME 1. English IME => Work 2. PinYin Chinese Input mode => Not Work (See attachment) 3. PinYin English Input mode => Work (See attachment) 4. Changjie / Quick Chinese Input Mode => Not Work 5. Changjie / Quick English Input Mode => Work So ... I guess , under the same IME say PinYin, the char code output for the same letter e.g. '2' are different for Chinese mode and English mode. ASCII ? UTF-8 ? ... I don't know ...
What I think is Pinyin Chinese mode--meaning that when I type syllables with Roman characters the IME window pops up to offer me Chinese characters--works for me, but what I suppose is Changjie, what M$ calls the Hong Kong IME, doesn't. I'm busy tomorrow but I'll explore some more on Thursday and try to figure out if the selection isn't getting set or if the IME is eating it the way the MacOS one did.
A comment in bug 796859 led me to test the order of setting the IME and starting GnuCash. If I start the IME first then the IME loses the selection; if I have the English IME selected, start GnuCash, and then switch to either PinYin or Hong Kong the selection is retained. Can you try that and see if it makes a difference for you?
(In reply to John Ralls from comment #18) > A comment in bug 796859 led me to test the order of setting the IME and > starting GnuCash. If I start the IME first then the IME loses the selection; > if I have the English IME selected, start GnuCash, and then switch to either > PinYin or Hong Kong the selection is retained. Can you try that and see if > it makes a difference for you? Hi John You r right! if the default IME is english. Autofill is working even changed to PinYin and Quick !!! This results is funny ...
It may be partly https://gitlab.gnome.org/GNOME/gtk/issues/1350. The first response there suggests that moving away c:\Program Files (x86)\gnucash\lib\gtk-3.0\3.0.0\immodules.cache might actually work as another work-around. You might test that as well.
(In reply to John Ralls from comment #20) > It may be partly https://gitlab.gnome.org/GNOME/gtk/issues/1350. The first > response there suggests that moving away c:\Program Files > (x86)\gnucash\lib\gtk-3.0\3.0.0\immodules.cache might actually work as > another work-around. You might test that as well. Cannot find this path and file under windows 10 ...
Dang, you're right. So no Gtk IME involved in the bundled GnuCash. Interesting...
BTW , some off topic questions , I have sent a email to gnucash-user@gnucash.org for some questions about gnucash (Question as below). However, there is not feedback at all ... <<< Hi Gnucash team I would like to know how to change the order of the account list in the pull-down menu during transaction register ? Seem some of the account is not well ordered. Regards >>> Can I know what is the right channel for such Gnucash Q & A ?
gnucash-user is the correct channel; there's also our IRC channel, #gnucash on irc.gimp.net. Your email with that question is in the list archives at https://lists.gnucash.org/pipermail/gnucash-user/2018-July/078210.html. You'll see that there are 5 other messages in the thread including two direct replies.
(In reply to John Ralls from comment #24) > gnucash-user is the correct channel; there's also our IRC channel, #gnucash > on irc.gimp.net. > > Your email with that question is in the list archives at > https://lists.gnucash.org/pipermail/gnucash-user/2018-July/078210.html. > You'll see that there are 5 other messages in the thread including two > direct replies. Thanks a lot. I found find the replies at the link above. It is straight that there is not any acknowledge to my email if there are any replies in the thread... Anyway, seem there is no way to change the sort order of the pull down menu (account) during transaction register, right?
David Carlson had a suggestion in the email thread, but in general, no--as I answered in the email thread. This isn't the right place to discuss it. And yes, replying to your email on the list is absolutely an acknowledgement.
(In reply to John Ralls from comment #22) > Dang, you're right. So no Gtk IME involved in the bundled GnuCash. > Interesting... Actually not correct. Mingw-w64 builds the immodules as statics so they're included in libgtk3.dll instead of being loadable modules, so there's no immodules.cache. However, switching the input to English before launching GnuCash means that Gtk doesn't detect that it's supposed to use the input module and doesn't enable it, so has the same effect. (The Gtk developers think that's a bug and opened https://gitlab.gnome.org/GNOME/gtk/issues/1375).
Alex, I think I've finally fixed this. Please test https://sourceforge.net/projects/gnucash/files/Development/gnucash-3.3-2018-10-27-git-3.3-49-g7280712c8%2B.setup.exe/download.
Never mind, I didn't get the IM set correctly. It still doesn't work. After a few more hours in the debugger I know why: None of the requisite code is getting called. The rest of this is for Geert to think about and to remind me what I discovered when I get back from travel in December: Neither gnucash_sheet_key_press_event nor any of the gnucash_sheet imcontext callbacks are getting called when the Chinese IM. gnucash_sheet_insert_cb is because it operates off of a signal from GtkEntry. gnucash_sheet and GtkEntry have separate im_contexts. With X11/Wayland and Quartz the GtkEntry one's callbacks are called, then the gnucash_sheet's callbacks. On Windows only the GtkEntry's im_context callbacks are called. When imcontextime is active it appears to disable other key event handlers. That leaves us with nowhere to restore the selection after the im_context has changed it for the preedit.
(In reply to John Ralls from comment #29) > Never mind, I didn't get the IM set correctly. It still doesn't work. > > After a few more hours in the debugger I know why: None of the requisite > code is getting called. The rest of this is for Geert to think about and to > remind me what I discovered when I get back from travel in December: > > Neither gnucash_sheet_key_press_event nor any of the gnucash_sheet imcontext > callbacks are getting called when the Chinese IM. gnucash_sheet_insert_cb is > because it operates off of a signal from GtkEntry. > > gnucash_sheet and GtkEntry have separate im_contexts. With X11/Wayland and > Quartz the GtkEntry one's callbacks are called, then the gnucash_sheet's > callbacks. On Windows only the GtkEntry's im_context callbacks are called. > > When imcontextime is active it appears to disable other key event handlers. > That leaves us with nowhere to restore the selection after the im_context > has changed it for the preedit. Noted. Thank you for your great support and waiting for gnucash team 's good news.
