Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Key pressed event bugs  (Read 2234 times)

0 Members and 1 Guest are viewing this topic.

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Key pressed event bugs
« on: October 26, 2015, 12:36:50 pm »
I found that KeyPressed event works incorrecly with language different than english.
Such event should produce keyCode which is independent on the keyboard localization.
For example if I presaing "q" it should always get keyCode Q. But it get localized chararacter instead of keyCode. It's really annoying bug, because there is no way to handle key independent feom current keyboard language.
Localized characters is good for TextEntered event, but it's real head pain for KeyPressed event.

I even can't imagine the reason why KeyPressed event returns localized characters instead of key codes. It's completely useless and meaningless.

It means that control keys, such as WASD for movement, will not works if a non-english keyboard is currently selected. So the user will not be able to control the game and even will not be able to know why.

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: Key pressed event bugs
« Reply #1 on: October 26, 2015, 12:38:51 pm »
There is need to rewrite KeyPressed event to notify key codes of physical keys and such event should not make any deals with any kind of localization.

It will also helps to solve a lot of bugs related to keyboard and will make keyboard source code of SFML much easier and easy localizable. Because it's a big mistake to mix physical key events and localization.

If you want to pass localized character of pressed key, then pass it in additional field, something like LocalizedCharacter, but please remove any kind of localization from KeyCode.
But I think it's a bad to place localized key in keypressed event, it may cause some troubles with some specific keyboard locales, such as chinise. It will be better to split it into separate event, something like CharPressed. But actually I think that such event will be useless. Because localization is used when user working with text, so it will be handled in TextEntered event.
« Last Edit: October 26, 2015, 12:54:37 pm by mkalex777 »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Key pressed event bugs
« Reply #2 on: October 26, 2015, 12:50:59 pm »
Don't double-post, especially if it's for full-quoting yourself... You can just edit your first post.

Yes, SFML returns the logical key, which depends on the current keyboard layout -- *not* the current language. So no, it's not "localized characters", it just returns the logical key pressed by the user.

We already discussed a way to add the physical key (scan code) to the API, but this is a complex subject. You'll find a complete discussion about it on the "General Discussions" board. There is also a task on the tracker for keyboard improvements, with links to the various related tasks and forum posts.

So please, next time document yourself before posting such requests ;)
Laurent Gomila - SFML developer

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: Key pressed event bugs
« Reply #3 on: October 26, 2015, 01:04:45 pm »
Hm, just checked it, yes, you're right it returns logical key. Actually I have issue because it raises TextEntered event even in case if the key press was already handled on KeyPressed event level.
Is there any way to set some kind of Handled flag to prevent key processing in TextEntered event if it's already processed in KeyPressed event?

I don't know why it's so complicated task, because I've done very similar task in my code some time ago. I was needed to support several API with different key codes (DirectX and XNA4), so I just added my own key codes enum and two mappings for each API. In such way I remapped my own enum used in the code into platform specific enum.  It was implemented with about 50 lines of code and works like charm.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Key pressed event bugs
« Reply #4 on: October 26, 2015, 01:12:40 pm »
Quote
Is there any way to set some kind of Handled flag to prevent key processing in TextEntered event if it's already processed in KeyPressed event?
No. But you should rather tell us what you're trying to do, I feel like there is a more elegant solution to your problem.

Quote
I don't know why it's so complicated task
What is complicated task?

Quote
It was implemented with about 50 lines of code and works like charm.
What's different with SFML? What prevents you from using the same logic?
Laurent Gomila - SFML developer

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: Key pressed event bugs
« Reply #5 on: October 26, 2015, 04:01:01 pm »
Quote
Is there any way to set some kind of Handled flag to prevent key processing in TextEntered event if it's already processed in KeyPressed event?
No. But you should rather tell us what you're trying to do, I feel like there is a more elegant solution to your problem.

Here is an example. When I pressing Tilde key it opens console.
But I dont want to process TextEntered event for Tilde key. Because it appears in console each time I open it.
I added the following code into begin of TextEntered handler to prevent such behavior:
            if (!IsOpen ||
                text == "`" ||                      // Tilde
                text == new string((char)27, 1))    // Escape (added because Tilde didn't works on Linux)
            {
                return;
            }
 

IsOpen - it's a flag which indicates that console is opened

It works ok with english keyboard layout. But when I switch layout to another language, this code receives localized character for the Tilde key. So it appears in the console and I have no idea how to eliminate it. Because there is no way to predict what character is assigned to the Tilde key on different keyboard layout.

So, the goal is to block TextEntered event for the key which is processed in KeyPressed event.
« Last Edit: October 26, 2015, 04:05:00 pm by mkalex777 »

 

anything