R devel - May 2022 - Writing in R // R 4.2.0 on Windows doesn't work with Dasher

On Sun, 15 May 2022 11:10:49 -0300
Paulo Barata <pb at infolink.com.br> wrote:
> I noticed today that R 4.2.0 responds to the "Enter" character of
> Dasher version 5.0.0 beta in "Direct Entry" mode. An
"Enter" in
> Dasher causes the R prompt to jump to the next line, as an
"Enter"
> should do.
> 
> No other characters (letters, digits, special characters like + = & ~
> | # $) are accepted by R 4.2.0 through Dasher.
This seems to be very similar to the problem discussed here:
https://stat.ethz.ch/pipermail/r-devel/2022-May/081683.html

For the record, here's the part of Dasher responsible for "Direct
Entry" on Windows:
https://github.com/dasher-project/dasher/blob/0ec7d646dbaadf06b8eebfc11b784738a20e75af/Src/Win32/Widgets/Edit.cpp#L302

MSDN says:
>> If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or
>> WM_KEYUP message to the foreground thread's message queue with
>> wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains
>> this message, passing the message to TranslateMessage posts a
>> WM_CHAR message with the Unicode character originally specified by
>> wScan.
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput>

Previously, Tomas Kalibera has mentioned:
> For Unicode Windows, GraphApp uses WM_IME_COMPOSITION messages to
> read the keys instead of WM_CHAR, which it uses for non-Unicode
> windows.
I think that for a combination of R >= 4.2 and Dasher, this means an
impasse. Either Dasher should be taught to send WM_IME_COMPOSITION
messages to R (?), or R should learn to understand WM_CHAR messages in
its Unicode windows in addition to WM_IME_COMPOSITION it currently uses.

-- 
Best regards,
Ivan

Mr. Krylov,

Thank you very much for you message. Yes, the Dasher issue seems to have 
some common ground with the other R 4.2.0 issue you have pointed out.

As I said, I know nothing about system programming, so I cannot 
contribute to a solution to these problems. I only stress that, as I 
said, Dasher 5.0.0 beta in "Direct Entry" mode works perfectly well
with
all the other software I use: e-mail, text editors, Internet browsers, 
etc., all of them with the latest updates, as it happens with my Windows 
10 Professional. Dasher works well with Windows' File Explorer, Windows'
Notepad, and Windows' Command Prompt.

Thank you once again.

Best regards,

Paulo

----------------------------------------------------------

On 15/05/2022 11:58, Ivan Krylov wrote:
> On Sun, 15 May 2022 11:10:49 -0300
> Paulo Barata <pb at infolink.com.br> wrote:
> 
>> I noticed today that R 4.2.0 responds to the "Enter"
character of
>> Dasher version 5.0.0 beta in "Direct Entry" mode. An
"Enter" in
>> Dasher causes the R prompt to jump to the next line, as an
"Enter"
>> should do.
>>
>> No other characters (letters, digits, special characters like + = &
~
>> | # $) are accepted by R 4.2.0 through Dasher.
> 
> This seems to be very similar to the problem discussed here:
> https://stat.ethz.ch/pipermail/r-devel/2022-May/081683.html
> 
> For the record, here's the part of Dasher responsible for "Direct
> Entry" on Windows:
>
https://github.com/dasher-project/dasher/blob/0ec7d646dbaadf06b8eebfc11b784738a20e75af/Src/Win32/Widgets/Edit.cpp#L302
> 
> MSDN says:
> 
>>> If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or
>>> WM_KEYUP message to the foreground thread's message queue with
>>> wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains
>>> this message, passing the message to TranslateMessage posts a
>>> WM_CHAR message with the Unicode character originally specified by
>>> wScan.
> 
>
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput>
> 
> Previously, Tomas Kalibera has mentioned:
> 
>> For Unicode Windows, GraphApp uses WM_IME_COMPOSITION messages to
>> read the keys instead of WM_CHAR, which it uses for non-Unicode
>> windows.
> 
> I think that for a combination of R >= 4.2 and Dasher, this means an
> impasse. Either Dasher should be taught to send WM_IME_COMPOSITION
> messages to R (?), or R should learn to understand WM_CHAR messages in
> its Unicode windows in addition to WM_IME_COMPOSITION it currently uses.
>

On 15/05/2022 10:58 a.m., Ivan Krylov wrote:
> On Sun, 15 May 2022 11:10:49 -0300
> Paulo Barata <pb at infolink.com.br> wrote:
> 
>> I noticed today that R 4.2.0 responds to the "Enter"
character of
>> Dasher version 5.0.0 beta in "Direct Entry" mode. An
"Enter" in
>> Dasher causes the R prompt to jump to the next line, as an
"Enter"
>> should do.
>>
>> No other characters (letters, digits, special characters like + = &
~
>> | # $) are accepted by R 4.2.0 through Dasher.
> 
> This seems to be very similar to the problem discussed here:
> https://stat.ethz.ch/pipermail/r-devel/2022-May/081683.html
> 
> For the record, here's the part of Dasher responsible for "Direct
> Entry" on Windows:
>
https://github.com/dasher-project/dasher/blob/0ec7d646dbaadf06b8eebfc11b784738a20e75af/Src/Win32/Widgets/Edit.cpp#L302
> 
> MSDN says:
> 
>>> If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or
>>> WM_KEYUP message to the foreground thread's message queue with
>>> wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains
>>> this message, passing the message to TranslateMessage posts a
>>> WM_CHAR message with the Unicode character originally specified by
>>> wScan.
> 
>
<https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput>
As far as I can see, Graphapp never looks for VK_PACKET.
> 
> Previously, Tomas Kalibera has mentioned:
> 
>> For Unicode Windows, GraphApp uses WM_IME_COMPOSITION messages to
>> read the keys instead of WM_CHAR, which it uses for non-Unicode
>> windows.
> 
> I think that for a combination of R >= 4.2 and Dasher, this means an
> impasse. Either Dasher should be taught to send WM_IME_COMPOSITION
> messages to R (?), or R should learn to understand WM_CHAR messages in
> its Unicode windows in addition to WM_IME_COMPOSITION it currently uses.
> 
Another possible solution for Paulo is to use R via some other front end 
besides RGui, e.g. RStudio, but there are other possibilities too.

Duncan Murdoch