Posted 11 years ago by Aaron W. Hsu
Version: 2.0.11
Avatar

When using a keyboard created from the Microsoft Keyboard Layout Creator with an AltGr key for creating special symbols, the editor will still recognize and AltGr sequence, like AltGr + SHIFT + T as a keyboard shortcut, when it should be recognized only as a character entry. Current behavior has the symbol inserted and the action specified by the Alt keyboard shortcut occuring.

Comments (4)

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Aaron,

The problem here is that Microsoft doesn't give us as WinRT developers any way to get proper text input.  The native WinRT TextBox and RichTextBox controls are the only ways a C# app developer can get composed input like what you want and from IME.  We reported this to Microsoft numerous times in the past (see this post for example:  http://social.msdn.microsoft.com/Forums/windowsapps/en-US/d32d7b82-a3a3-4f48-a8ca-c4974a425f3b/missing-uielementtextinput-events-and-related-types) but so far they have not responded even indicating they will help add something to allow proper character input in custom controls.  It's been very frustrating.  I would urge you and other Code Writer users to also reach out to them and tell them you want C#-based custom control developers to be able to support IME and other text input properly via Microsoft's WinRT API.  We will be happy to enhance our SyntaxEditor for WinRT control (which is the code editor portion of Code Writer) to support this as soon as it's available.


Actipro Software Support

Posted 11 years ago by Aaron W. Hsu
Avatar

Thank you for the response. I did a quick look over that message in the Microsoft forums, but it seems like you're talking about getting the character strings typed by a composed character. In my case, Code Writer *does* work to enter my composed characters from AltGr+<key> when I type them. However, if the AltGr+<key> sequence happens to also correspond to an Alt+<key> shortcut sequence, then not only does it insert the composed character, but it also activates the keyboard shortcut. It is this last part that I would like to avoid. I'm not sure how Windows handles these things.

In particular, I know that on other Operating Systems some applications incorrectly recognize raw Alt keycodes when recognizing shortcuts, rather than checking whether those Alt keys actually map to the "Alt" symbol in the keymapping or if the key has been remapped to another meaning, such as Ctrl or Compose. It seems that Code Writer at the moment does not distinguish from Alt and AltGr keys when using a keyboard created with MKLC that uses an AltGr key (that is, remapping the Right-Alt to an AltGr).

Are you saying that Code Writer cannot distinguish the difference, between, say, Alt+Shift+T and AltGr+Shift+T? This seems like something different than recognizing the strings received by the AltGr+Shift+T sequence itself. Code Writer does already successfully allow me to enter special characters, so I'm okay on that front. However, most of the applications I use are able to tell the difference between AltGr and Alt sequences, but it seems that Code Writer is not able to do so.

Posted 10 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello, I'm looking at the Microsoft WinRT API reference (it's pretty sparse in terms of what they give us for keyboard input) and I don't see any references to AltGr.  Unfortunately I'm not sure how we can programmatically determine if the right Alt has been mapped to another meaning or not.  It seems that AltGr maps to Ctrl+Alt, so by using the AltGr+Shift+T hotkey, we end up effectively seeing Ctrl+Shift+Alt+T, which is transpose lines.

It looks like that hotkey is the only one we have that has Ctrl+Alt and a letter key, so we will change it to just be Shift+Alt+T for the next version to avoid conflicts with AltGr.  That combination is what Visual Studio appears to use too.


Actipro Software Support

Posted 10 years ago by Aaron W. Hsu
Avatar

Thanks for the explanation. It makes sense that it might work like that. If there are no conflicting characters that seems to be a good workaround, especially if Microsoft doesn't offer anything else. Thanks for the information!

The latest build of this product (v4.2.42) was released 3 years ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.