The issue of the scroll bar jumping when inputting TRichMemo in Chinese

[jianwt]

In the state shown in Figure 1, when continuing to input Chinese on a new line, the vertical scroll bar should smoothly move downward. However, as Chinese is input, it starts to scroll in a jumping manner, taking on the appearance shown in Figure 2. The characters input on the previous line are completely invisible. How can this be solved?

I'm using Windows 10, lazarUS3.4, and GTK2
Set RichMemo1.ScrollBars:=ssBoth

When you input Chinese in TMEMO, the vertical scroll bar will scroll normally.

[jianwt]

A video showing problems with the vertical scroll bar.

[Martin_fr]

I don't know about TRichMemo...
But which IME are you using? There seem to be several for Chinese.

Maybe its related to https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41755
 (i.e. Maybe the Richmemo reacts to the keyup messages...)

[jianwt]

@ Martin_fr
I use the "Sogou" Chinese input method software。
Download address：
https://shurufa.sogou.com/windows

[Martin_fr]

Sorry, didn't notice: gtk2 => the issues I linked is Windows.

I can't get any such behaviour on Windows. Only a small movement in the scrollbar, because the line height changes, an the Chinese chars need more vertical space.

In your case, I don't know if it is
- gtk2
- the IME itself
- richmemo.


Maybe additionally open an issue with the author of richmemo?

[jianwt]

@Martin_fr
Thank you for your attention and answer.

Based on the existing characters in my routine, after making a carriage return and line feed at the end of the string, and then continuing to input Chinese (using the Chinese input method software I provide，https://shurufa.sogou.com/windows), you will find that the scroll bar does not move slightly but moves in a leapfrog manner.

The problem occurs roughly when the input characters are approaching the bottom of the current RichMemo interface, a pop-up page flip will appear.

Only by dragging the vertical scroll bar upwards with the mouse can the previously entered characters be seen.
Download address for input method software：
https://shurufa.sogou.com/windows


According to general input habits, even when the string is almost at the bottom of the RichMemo interface, the vertical scroll bar should move down slowly instead of displaying the character just entered as the first line of the current interface (which is not actually the first line). What I mean is that the line jumps too much when inputting characters to the bottom of the interface. See the two pictures I sent on the first floor.

I translated it with a translation software, but the meaning may not be accurate. Therefore, I posted another video of the problem on the second floor (99.zip), which can be downloaded to watch the specific phenomenon of the problem.

It is estimated that when inputting Chinese, the method of calculating the distance moved by the vertical scroll bar might be different from that in English. This is precisely why there is no problem when inputting English.

[Martin_fr]

Unfortunately I wont be able to help at all.

My previous comment was by mistake. => If it had been on windows, it could have been related to an issue with the IME on Window (and that is a Windows only issue). That issues on Windows, allows keystrokes to incorrectly have an effect outside the IME. So if it had been Windows, those keystroke could maybe have triggered the scrollbars.
But, its not Windows.

For all else, unfortunately I am not familiar with any of the underlaying implementations.
- I don't know the gtk2 stuff at all
- I don't work on Richmemo (this is provided by a 3rd party / they need to look at it)
- I don't do much IME work.

As for IME: I don't speak/write any of the Languages that use an IME. I would normally not work on it at all. I had some contact with it, due to my work on SynEdit, Windows only (fun typing into an IME, if you have no idea what the symbols mean...). If it wasn't for that, I would not be looking at the window IME issue either. But since I know tiny bits of the Windows API for it, I gave that Window related bug a a go...
As your issue turns out not to be related to that at all, well sorry, but way outside my area of expertise.

I am not even sure who wrote the LCL side abstractions for IME... Otherwise I might ping them. But since I don't... If they don't read this by chance, then to contact the LCL maintainer for gtk2 IME someone has to check the git commit logs for whom to ping. (And whoever it is, they may first want to see a comment from the Richmemo author, if the issue is richmemo only - as it is then more likely to be a fault in richmemo).

[rvk]

Are you sure that edit-pulldown-box isn't messing with the component?
Try copying some characters and then only paste those characters instead of calling that box.

[jianwt]

Martin_fr@rvk
I tested it again on the Windows 7 system. There was no such phenomenon. When inputting Chinese, the vertical scroll bar moved perfectly. However, under the Windows 10 system, there is a problem. I don't have the Windows 11 system and thus can't test it.

The issue of the jumping display when inputting Chinese in RichMemo is indeed related to the system. I tested it again under the linux system and there were no problems either.

The following picture is a screenshot of the input I tested under the Windows 7 system.

[rvk]

So, the problem is only under GTK2 on Windows 10? Nowhere else?

I tried on Windows 10 without GTK2 and it seems fine.

I'm using Windows 10, lazarUS3.4, and GTK2
Set RichMemo1.ScrollBars:=ssBoth

Any reason for GTK2 under Windows?

[jianwt]

Maybe there's something wrong with my computer? It's haunted!!

[rvk]

Ok. In your openingspost you mentioned GTK2.

Did you try only copying the Chinese characters into the richmemo?
I didn't use that extra software you have to type text.
(I copied text from https://www.jademond.com/tools/chinese-filler-text/ )

[jianwt]

@ rvk
That problem will not recur when pasting. This phenomenon only occurs when Chinese input is in progress. This phenomenon also occurs when I choose to compile on WIN32/64.

[Martin_fr]

Ok. In your openingspost you mentioned GTK2.

Did you try only copying the Chinese characters into the richmemo?
I didn't use that extra software you have to type text.
(I copied text from https://www.jademond.com/tools/chinese-filler-text/ )

The report says the problem happens with the IME. So copying is 99.9% unlikely to cause the issue.

Almost any IME has such a dropdown (candidate window).

In Chinese you have more chars than keys. To enter chars you (afaik) type a key or key-sequence that represents a Chinese char (or word?). However there isn't a one to one mapping. You get a list o possible candidates.  A little bit like code completion.

Normally that drop down is done by the IME => the control (rich memo) does not have control over it. The richmemo will however be asked where it should be placed. So it could react to that. Including wrongly react to that.

I don't know the exact way it works on gtk2. But on windows (there are different level of integration), on windows the following may happen.

- The IME asks richmemo where to place a dropdown  (and tells the size of the dropdown)
- The IME then needs the unfinished text to be painted (this is not yet typed into the richmemo).
   For that it can either
  - ask where
  - if richmemo agreed, then give the text to richmemo (maybe including layout/size)

So if richmemo mixes up any of the above, then richmemo could think it needs more space to have the "unfinished text" displayed.

Because, yes, for the unfinished text, it could rightly decide to scroll.
But for the completion drop down, it should not.

But all the above are guesses... could-be, don't have to be...

Anyway, it is possible there is a bug in richmemo.
Maybe the IME in question uses a different way to communicate (could still be correct, just different).

E.g. (Windows again), even different IME by Microsoft themself expose very different ways to use the Windows API to tell a control what happens. It's easy for a control to get confused by one of those ways...


Unless the Author of richmemo happens to read this by pure chance, it is highly unlikely anyone here will be able to do anything but wildly speculate. Hence I think it needs to be reported at the richmemo site.

[rvk]

That problem will not recur when pasting. This phenomenon only occurs when Chinese input is in progress.

So... that means the problem is probably with that piece of software you use to "type" Chinese characters.

You can try to copy one character and paste it instead of typing. If with adding one character each time (and an enter at some interval) you still don't get the problem, then it's definitely that software.

Cab you post the RTF source of the text which gives you problems?
Maybe the IME adds too much text (invisible characters) ?

Does the problem occur when you load in that RTF and do nothing?
If not, it must be that dropdown window that's messing with things.

O, and did you try the IME from Microsoft itself?
https://support.microsoft.com/en-us/windows/microsoft-traditional-chinese-ime-ef596ca5-aff7-4272-b34b-0ac7c2631a38