Messages

1

General / Re: Trapping function keys

« on: February 08, 2013, 02:25:19 pm »

I can probably disable this special behaviour in SFML, but first I'd like to find what it's supposed to mean for the OS.

F10 : In Microsoft Windows activates the menu bar of an open application.

It's pretty much the same behaviour as the "ALT" key.

Agreed.  Pressing ALT highlights or unhighlights the menu bar, and pressing F10 also highlights or unhighlights the menu bar.  Laurent, if you want more reference info, here are a couple of links.

Keyboard shortcuts which mention F10:
http://support.microsoft.com/kb/126449

Reference about WM_KEYDOWN which mentions F10:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646280%28v=vs.85%29.aspx

2

General / Trapping function keys

« on: February 21, 2012, 08:42:35 am »

See this page:

http://devmaster.net/forums/topic/8587-help-with-wm-keydown-sc-keymenu-f10-key-press/

I ran into this myself, and I solved this by changing the SFML library in WindowImplWin32::GlobalOnEvent as follows.

Before:

Code: [Select]

   // We don't forward the WM_CLOSE message to prevent the OS from automatically destroying the window
    if (message == WM_CLOSE)
        return 0;


After:

Code: [Select]

   // We don't forward the WM_CLOSE message to prevent the OS from automatically destroying the window
    if (message == WM_CLOSE)
        return 0;

    // We don't forward WM_SYSKEYDOWN and WM_SYSKEYUP messages for VK_F10 and
    // the alt keys to prevent Windows from pausing the game and trying to
    // activate a menu bar.
    if (((message == WM_SYSKEYDOWN) || (message == WM_SYSKEYUP))  &&
        ((wParam == VK_F10) || wParam == VK_MENU))
    {
        return 0;
    }


Laurent, feel free to use this in the official library code if you like, and it seems reasonable to you.  

3

Window / SFML 2.0 sf::RenderWindow freeze when Control-C pressed

« on: February 16, 2012, 09:25:29 am »

The problem appears to be that SwapBuffers hangs internally (calledby SFML).  My workaround is to manually set a Control-C/Control-Break handler using SetConsoleCtrlHandler (http://msdn.microsoft.com/en-us/library/ms686016).  I would presumably use sigaction with SIGINT and SIGTERM under Linux/Mac.

At any rate, in the control handler, I changed some engine state so that my game loop would end itself cleanly.  If I am not mistaken, merely shutting down my engine (and presumably SFML in the process) in the control handler caused a crash because my main thread would still potentially be in the middle of rendering and/or using engine data structures.

I think this solution is acceptable, but if anyone familiar with SFML has additional comments about console Control-C handling while SFML window code is running, please feel free to share.  

4

Window / SFML 2.0 sf::RenderWindow freeze when Control-C pressed

« on: February 16, 2012, 08:47:17 am »

Hello,

I am using a recent build (LaurentGomila-SFML-e7256e3) of SFML 2.0.  I have an application configured to use the Windows console subsystem (running under Windows 7), and this allows me to print debug information to the console.

If I have a window open in even a simple application loop that includes window.Display(), the Display() call seems to freeze forever if I press Control-C in the console window.  The window closes, but the Display() call is frozen so the application does not exit.  I can post code if needed, but it should happen with any such test program.

Could this be due to a strange sleep value due to Display() attempting to maintain the frame rate after the window is closed?

Thanks very much for your time!