locked
Global keyhook on windows 8 - metro part

    Question

  • I am developing a screen capture application in MFC C++ that captures the screen when i press Alt+3. The app works great in Windows 8 Desktop mode but when i switch to metro UI and press alt+3 nothing happens, but after i click the WinKey (switch to desktop mode) my app gets activated and shows me the captured metro UI.

    Question: Is there any way(WinAPI or the new api) to switch from metro UI to desktop mode?

    As i see the my application is activated and the screen is captured like it should be but the problem is that the metro UI is covering my application so i can't see the screen shout

    you can test this with http://pokit.org

     

    It would be nice to have a standard winapi to see if metro UI is activated. But maybe this could be done wit a hack - to see the frontwindow title if it is metro UI then send the WinKey to switch to desktop mode.


    • Edited by Cruonit Tuesday, October 04, 2011 7:21 PM
    Tuesday, October 04, 2011 7:16 PM

Answers

  • Hi Cruonit,

    I assume that you're calling SetForegroundWindow (or a moral equivalent) to try to bring your window into the foreground.

    SetForegroundWindow is protected to prevent applications from stealing the foreground away from the application that the user is actively using (see http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx for the Windows 7 details).  There are some loopholes in these protections, and Windows 8 tightens down the restrictions to prevent Desktop apps from stealing the foreground from Metro style apps.  Some of these additional protections were a bit tighter than intended and are blocking some legitimate scenarios (such as setting foreground from a user-triggered hotkey).  We're investigating how to better allow legitimate scenarios while still blocking loopholes.  In the meantime, the only solution will be to have your users explicitly switch to your application after capturing the screenshot.

    An application sending a WinKey to try to switch to desktop mode is exactly the sort of loophole that we're trying to prevent.  Applications should not steal the foreground: users should be in control of that.

    Not related to the foreground change, I'd recommend replacing your application's global keyhook with a hotkey (see RegisterHotKey: http://msdn.microsoft.com/en-us/library/ms646309(VS.85).aspx ).  Global hooks are very heavy-weight and expensive.  They are very difficult to get working correctly (easy to get to work in simple testing: hard to get to work correctly).  In modern OSes there are almost always much better ways to achieve the behavior most apps use global keyboard hooks for than to use global hooks.

    --Rob

    Monday, October 10, 2011 11:38 PM
    Owner

All replies

  • Hi Cruonit,

    I assume that you're calling SetForegroundWindow (or a moral equivalent) to try to bring your window into the foreground.

    SetForegroundWindow is protected to prevent applications from stealing the foreground away from the application that the user is actively using (see http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx for the Windows 7 details).  There are some loopholes in these protections, and Windows 8 tightens down the restrictions to prevent Desktop apps from stealing the foreground from Metro style apps.  Some of these additional protections were a bit tighter than intended and are blocking some legitimate scenarios (such as setting foreground from a user-triggered hotkey).  We're investigating how to better allow legitimate scenarios while still blocking loopholes.  In the meantime, the only solution will be to have your users explicitly switch to your application after capturing the screenshot.

    An application sending a WinKey to try to switch to desktop mode is exactly the sort of loophole that we're trying to prevent.  Applications should not steal the foreground: users should be in control of that.

    Not related to the foreground change, I'd recommend replacing your application's global keyhook with a hotkey (see RegisterHotKey: http://msdn.microsoft.com/en-us/library/ms646309(VS.85).aspx ).  Global hooks are very heavy-weight and expensive.  They are very difficult to get working correctly (easy to get to work in simple testing: hard to get to work correctly).  In modern OSes there are almost always much better ways to achieve the behavior most apps use global keyboard hooks for than to use global hooks.

    --Rob

    Monday, October 10, 2011 11:38 PM
    Owner
  • Hello Rob,

    I work on a disabled communications application where I need to hand out standard wireless keyboards to people to type on.  Often, people accidentally hit the Windows key and it interrupts the application that they are trying to communicate with.  Physical Keyboard modifications (such as removing the Windows key) are not helpful for this specific situation as this is also an application I eventually want to sell, so that people can use standard off-the-shelf keyboards.

    There are some important use cases such as videogames that can be disrupted by an accidental press of the windows key.   

    What can I do in Windows 8?   How about permitting Windows keys to be disabled on secondary and tertiary keyboards that are simultaneously connected (but not being disabled on the main keyboard)?   This is an acceptable compromise to me.  (Using advanced API's, I am able to tell which keyboard that the keypress came from, but I cannot suppress the LWIN or RWIN keys in these legitimate disabled communication scenarios!)

    Wednesday, May 30, 2012 4:09 AM