ALL,
We have a an application written with wxWidgets (wxGTK) and Qt.It is running on RHEL6 with FVWM window manager.
One of the window we have in that application is "Lock Screen" which is shown in the full-screen mode and does not have any decorations. The only way to get out of it should be to enter the password and press the "Authenticate" button.
However what we discover is that if the user starts up Terminal and then pulls up that "Lock Screen", (s)he can press ALT+TAB, switch to the Terminal and type whatever (s)he wants. We'd like to avoid it.
Is there any way possible to catch the "ALT+TAB" keystroke and do nothing when this "Lock Screen" window is displayed. The window is written with wxWidgets, but I'm asking about c++/Linux/gtk/qt in general.
TIA for any hints/advice community can provide.
[EDIT]
All I want is for the user to not be able to switch focus from the password field until the password is given and the "Authenticate" button is pressed.
[/EDIT]
And before you ask - there are couple of related questions on SO, which says solved, but they are for Windows/C#/WinForms/JAVA. If you can find something that will work on Linux with either GTK or Qt or maybe even FVWM internal settings I will gladly accept the answer.
Related
I need a context menu entry for each program in the taskbar. Want to add an entry which immediately terminates (UNIX/Linux-like signal SIGKILL) the process. There a lot of questions on this site, how it's done for the explorer or desktop. But is it also possible to add such an option to the context menu of the taskbar?
To clarify the question, according to my comments:
The current problem:
I have a program (not Firefox) which randomly crashes. The program is in fullscreen mode. But if I want to close the window of the program with Exit window, it takes a long time that Windows kill the program. When I try to open the Task Manager the program immediately grabs the user input and I have no chance to interact with the Task Manager. So my solution was to add a context menu item in the taskbar to quit the task of the program. According to a user comment, I test the option "Always on top" in the Task Manager. Didn't know that. But I haven't tried it yet. I'm also interested for further projects, if there is a function in WINAPI or Windows Registry to add an item.
To avoid down-votes:
I'm not interested to hack Windows or the application. Solutions with code injection are taboo for me. Want a clean solution, if even possible. I want improve my Windows version. Adding also some additional information (process information) in the context menu.
Have currently found this (Registering shell extension handlers).
Has anybody used this before? I think it's sound promising.
There is no API to extend this menu like that. Applications can customize the top of the menu with ICustomDestinationList but there is no way to add entries for all applications.
For a personal use project, you could inject a .dll in the taskbar instance of Explorer.exe and add your item after figuring out the address of the function where the menu is created. This address can of course change after you upgrade Windows so it is not a very generic solution. Using the public symbols might help but you still have to expect it to break from time to time when Microsoft changes part of their taskbar code.
You don't need to change code in explorer.exe, because you can close a program by doing the keyboard shortcut: Alt + F4.
Background
I'm implementing a simple WIN32 application consist of a window.
The user may show/hide the window using a special hotkey. I register the hotkey using RegisterHotKey and respond to WM_HOTKEY
Problem
if user plays a game and accidentally (or not accidentally) press the hotkey combination, then my window pops up and as a result the game is minimized.
Question
Is there a (native) way to know that the user is in gaming mode, or any other special mode, that I could disable the hotkey response
Note
I would also like if windows would make this a feature while I play games. For example don't respond to WinKey+D while I'm in gaming mode.
You can use the SHQueryUserNotificationState function to determine whether the user is playing a full screen D3D game. It will report QUNS_RUNNING_D3D_FULL_SCREEN.
I've written a win32 App in C++ (a game) and I want to be able to know if the application has lost focus due to the user pressing CTRL-ALT-DEL and starting the task manager. How can I do this? What I want to do after detecting the event is to minimize the window of my game and pause its processing (animations, audio, etc.). However, if the user returns from the CTRL-ALT-DEL menu to the game then it should keep running as usual. I've thought that I could check for key presses on CTRL, ALT and DEL but that doesn't seem to work and just reacting to the lost the focus (WM_KILLFOCUS) is not what I want.
You can use WTSRegisterSessionNotification(), you'll get the WM_WTSSESSION_CHANGE message when the user presses Ctrl+Alt+Del and switches to the secure desktop.
Beware that you cannot tell that it was actually the secure desktop that he switched to, that would be rather nasty security leak. You'll also get the notification when he switches to another logon session. Also a case where you want to stop your game of course.
For that matter, a game ought to automatically pause whenever the game window loses the foreground. Nobody likes to be killed when they switch to their email reader :) Use the WM_ACTIVATEAPP message
I am working on an application for a customer and have hit a problem.
The application talks to the mobile phone and does a bunch of call handling. One of the things it does is to show an "answer call" button. Clicking this with the mouse works fine.
But the customer wants to have a keyboard shortcut for this, and that's a problem. I can get the focus if a window in the application has focus. But Windows focus steal prevention doesn't allow me to take focus if the user is in a different application.
Please don't discuss the pros and cons of focus stealing here. I know them already and have given them to my customer. Wrong or not, they still want to do this, and they are paying the bill, so they get to decide.
There are a number of workarounds for this, but they do not seem to work anymore. For example, I set HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundFlashCount to 3 and ...\ForegroundLockTimeout to 0.
So what are my options? Is this impossible? Or do I have to build a keyboard hook application that virus checkers will hate?
This is a Qt/C++ application, but if you have C# example code that can do this, that is great as well.
I hope you can help.
I do not know how dated this is but you could try RegisterHotKey.
It allows you listen for keyboard events system wide and not just when your application has focus. You don't have to provide your window handle, if you leave that argument null the events are still posted to your thread.
I am currently developing a user interface DLL that uses the WIN32 API. The DLL must work for numerous platforms, XP, WIN CE, etc. I have managed to incorporate docking, anchoring and so on but appear to have a problem regarding owner-drawn buttons. I can draw the button's correct state, focus, clicked, default. However, I cannot receive key notifications. I specifically want to perform a click operation on a button that currently has focus, should the user press enter.
Note that I am using a windows message loop rather than a dialog message loop. I use windows hooks to hook into the window creation and set the user data to 'point' to my control instance. If I test for WM_KEYDOWN in the main message loop I can get a handle to my button control instance and could forward the message to the relevant control. Unfortunately, I am dealing with a lot of legacy code and this may not be an ideal solution.
So, my question is what is the best way forward. Is subclassing the button control's window procedure a viable option or is there an easier way?
Many thanks in advance.
The comments above are correct. The button with focus should be getting the key messages. But buttons don't (by themselves) respond to Enter--they respond to Space. It sounds like what you're missing is the typical dialog keyboard navigation, like Tab key moving the focus and Enter activating the "default" button.
If you've got a typical Windows message pump, and you want the keyboard behavior normally associated with dialogs, then you need to use the IsDialogMessage API in your message loop. This means your window is essentially a "modeless dialog".
Looks like standard window proc subclassing should do the trick. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx for details.