On Sun, 15 May 2022 11:10:49 -0300 Paulo Barata <p...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
