Disabling Alt/control/shift

[Spaceage15]

Is there a way to disable these keys or pause the app when these keys are pressed. I've searched and havent really got an answer. I've seem notes saying that sfml fixed bugs for Alt/control/shift but when I hit the key, it still affects my App.

I anybody have any ideas please let me know

[Nexus]

I think you can normally handle the KeyPressed event and check if the key code is equal to one of the following:

Code: [Select]

sf::Key::LControl
sf::Key::RControl
sf::Key::LShift
sf::Key::RShift
sf::Key::LAlt
sf::Key::RAlt

[Laurent]

What do you mean with "disable these keys"? If you don't handle them in your program, nothing will happen.

[Spidyy]

If we hit the alt key, even by handling it, it make the window lose focus.

In SFML 2.0, I added this lines on the WindowImplWin32::GlobalOnEvent() function to ignore the alt key message :

Code: [Select]


if (message == WM_CLOSE)
return 0;
// Ignoring Alt key system message (Added)
if (message == WM_SYSCOMMAND && wParam == SC_KEYMENU)
return 0;


It prevent the focus lose and allow me to use the Alt key from the SFML events.

[Laurent]

That's right. But I don't know if it's wise to disable system-specific hooks. I mean, maybe some users actually use these shortcuts

[Spidyy]

Each game has it's own behavior with system keys.

For example, MAME allow to use Shift, Ctrl and Alt as control. It don't disable the Alt+Tab combo or other system combo.

I think it is a decision the programmer should take before the user. =p

[Laurent]

I disagree, the OS global shortcuts should be consistent and always work with any app. I agree that it's often convenient to "steal" ALT for your own purpose, but think about the other shortcuts like ALT+F4, CTRL+ALT+DEL, etc.

Anyway, this is probably never going to be implemented in SFML (window.DisableAltOnWindows() ? :lol:), so...

[Nexus]

If we hit the alt key, even by handling it, it make the window lose focus.

Is this really the case? I couldn't reproduce that behaviour on Windows 7. I think, ALT is only an issue in combination with other keys like TAB or F4.

I disagree, the OS global shortcuts should be consistent and always work with any app. I agree that it's often convenient to "steal" ALT for your own purpose, but think about the other shortcuts like ALT+F4, CTRL+ALT+DEL, etc.

In my opinion, it might be useful to "overload" ALT+F4 for the same reason we can connect the [X] (sf::Event::Closed) to a custom action, like saving data or confirming exit. With other words: Using your argumentation, SFML should also leave the default [X] functionality instead of allowing the user to customize it. A lot of games (and also other software) catch ALT+F4 and ask the user to save the program state, and I don't think this approach is fundamentally wrong.

Nevertheless, I see that it's problematic to implement the customization in a portable way, since the shortcuts are very platform-dependent.

[Laurent]

Is this really the case? I couldn't reproduce that behaviour on Windows 7. I think, ALT is only an issue in combination with other keys like TAB or F4.

Alt gives focus to the menu, and if there's no menu, it still makes something but it's not clear what

In my opinion, it might be useful to "overload" ALT+F4 for the same reason we can connect the [X] (sf::Event::Closed) to a custom action, like saving data or confirming exit

sf::Event::Closed is not connected to [X], it is connected to the close event of the window. Therefore, sf::Event::Closed is triggered when you hit ALT+F4 as well.

Using your argumentation, SFML should also leave the default [X] functionality instead of allowing the user to customize it

Technically this is the same thing, but in practice we both know that this feature is implemented for giving the ability to ask for saving before closing. So it's not really a way to disable or change the OS behaviour, just a way to insert custom code before finishing

[Beta_Ravener]

What about sf::RenderWindow.SetFocus() ? Looks like only problem is that you loose focus to that window and jumps to menu bar (which in SFML isnt but I observed drop down menu instead). This wouldn't disable system calls, and would allow user to treat alt also. If you would like to use this invisible menu, you just wouldn't call SetFocus after pressing alt right?

Edit: Can't figure how to take control from menu to screen. Other solution would be sf::RenderWindow.EnableSystemShortcuts() maybe, which would enable/disable catching of all keys. This would leave choosing whether or not use them on programmer. At this time you are forced to use them unless you modify code as above...

[Nexus]

Alt gives focus to the menu, and if there's no menu, it still makes something but it's not clear what

I didn't notice before, but at a closer look, I found out that the left ALT expands the window menu (the one with minimize, move etc.), while the right ALT (ALT GR) works normally. The focus was kept in both cases (I checked the LostFocus event).

But that makes the left ALT key effectively useless on Windows, doesn't it? Even the realtime input (sf::Input::IsKeyDown()) reacts with a delay every second time.

sf::Event::Closed is not connected to [X], it is connected to the close event of the window. Therefore, sf::Event::Closed is triggered when you hit ALT+F4 as well.

Ah, very nice, I didn't know that.

[Nexus]

So, there is currently no way to meaningfully work with the left ALT key in a SFML application, and this will rather not change in a future release, correct?

If so, I'd probably consider the code shown by Spidyy a workaround... Or is there a better alternative (except not using ALT)?

[Laurent]

So, there is currently no way to meaningfully work with the left ALT key in a SFML application, and this will rather not change in a future release, correct?

Correct.

If so, I'd probably consider the code shown by Spidyy a workaround... Or is there a better alternative (except not using ALT)?

I don't think so :?

[Nexus]

Okay, thank you.

Up to now, I have got along without ALT in my games. But when the day comes, I'll hopefully remember this thread.

[Tex Killer]

Hello, and I'm sorry for bringing on such old topic, but...

Over here you said that there was no way of using menus with only SFML (without a GUI).
Why would you want a system menu effect to be active on plain SFML?
Wouldn't it be better to left it disabled, and make a method to activate it (for future GUIs to call it)?

By the way, thanks for the time and effort.