New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange RichEdit behavior in Burn with Turkish keyboard #5843

denis-gz opened this Issue Jul 9, 2018 · 0 comments


None yet
2 participants
Copy link

denis-gz commented Jul 9, 2018

Steps to reproduce:

  1. Prerequisites: Have some Burn-based installer, configured to use standard WixStdBA module with RtfLargeLicense theme. For example, vcredist_x86.exe from MSVC2015 will do.
  2. Install Turkish language in the system, along with Turkish keyboard layout (e.g. TRQ)
  3. Open CMD console, switch to TRQ layout (or just run from Desktop with TRQ layout active)
  4. Run the installer you prepared
  5. Quit installer, either cancel or let it run to the end
  6. Notice the active keyboard layout, on step 3 and step 4

Expected result:

Active keyboard layout doesn't change (so it still should be TRQ on step 3 and 4).

Actual result:

Active keyboard layout changes to the previous one before TRQ was set (e.g. ENG).


The strange thing is this is only happening with Turkish layouts. Spanish, German, Russian, etc. does not show such behavior with Burn.

As I was able to investigate, the bug concluded in RichEdit control which is used in RtfLargeLicense theme. For some reason, the code inside RICHED20.DLL calls ActivateKeyboardLayout with different layout than currently selected. Previously GetKeyState with VK_SHIFT argument reports incorrect state for Shift key(s), so may be this triggers the bug (this doesn't happen with other layouts).

Suggested fix/workaround:

Just use newer MSFTEDIT_CLASS when you create RichEdit control, instead of older RICHEDIT_CLASS which is used currently. This change also implies changing the library to load - MSFTEDIT.DLL to replace RICHED20.DLL. This library exists on at least Windows XP SP3 (cannot check older SP) and later versions, and works perfectly as a drop-in replacement. Probably other issues could be fixed as well, as on Win10, this is of version 3.1 vs. version 8.5 of MSFTEDIT.

@barnson barnson added this to the v4.0 milestone Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment