I am hosting a web browser control, and I don't know how to fetch hotkeys such as [F1] when the control has focus.
My primary need is displaying custom help when the user presses F1, however, generally being able to provide additionla shortcuts would be nice.
(additional information is available at my related question - I hope it was the right choice to open a second question - I guess the solutions aren't related.)
Nothing simpler; your ActiveX control should have essentially a WINPROC in it. It may be hidden by a BEGIN_MESSAGE_MAP macro list, but it's there if you have a window.
Simply handle the windows message events (i.e. WM_KEYPRESS) in the WINPROC and you're set.
Related
In any web browser and in the Windows file manager and in many other applications there is support for forward and backward navigation. This always (or at least most of the time) by default works with extra mouse buttons if your mouse has any.
I want to implement this in a C++ application I'm making based on WinAPI. However I wonder how one would do this? Are the mouse buttons captured "manually" in each application that has this forward/backward navigation or is there native support for it somewhere in WinAPI?
Manually capturing the buttons is probably always an option, but if there already is an existing functionality that handles this then it seems like that should be used instead. That's probably more reliable as well.
To sum up: I want my application to correctly handle/receive backward and forward clicks from a mouse that has such buttons.
The WM_APPCOMMAND message offers the APPCOMMAND_BROWSER_FORWARD ("Navigate forward") and APPCOMMAND_BROWSER_BACKWARD ("Navigate backward") navigation commands. You can handle them in your application, even if it's not a browser.
The documentation has information, how and when the WM_APPCOMMAND is generated:
DefWindowProc generates the WM_APPCOMMAND message when it processes the WM_XBUTTONUP or WM_NCXBUTTONUP message, or when the user types an application command key.
Is it possible to create a keyboard shortcut to switch between the monitor and portion selection of this wacom preferences window, via a c++ console program?
Sorry if this is poorly worded, I've had trouble trying to find the right words to search for ways to do it.
I think it should be possible, although a bit tedious. You should be able to use the Windows API, and try to EnumWindows/EnumDesktopWindows to identify the respective application Window, and its respective controls (which are also Windows).
You should identify the window title, and class ids, for the app window, and the checkbox button controls, then when you enumerate through all the desktop windows, you can identify the ones you are interested in.
Then you can use the SendMessage() API to send messages to the controls (Windows) of interest to manipulate them.
It's a bit tedious, but sounds possible.
An example of use here to get an idea:
http://www.cplusplus.com/forum/windows/25280/
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.
Having setup C++ app originally using MS specific keyboard journaling hook (WH_JOURNALRECORD) we find that it does not work on Vista unless run as administrator with uiAccess enabled. MSDN Question - Journaling hooks on Vista?
We want to record a key sequence from the user in a friendly way that will be repeated at some later date. The user presses a record button, a dialog is displayed with a stop button and the recorded keys.
One advantage of using the journaling hook was that you only got keystrokes which did something. Holding down shift didn't report 100 shift keys, but did report usage when you hit a letter.
Another advantage was that you could set the focus to an area outside of the application, say another applications window, and record the action as the user interacted.
Asides from making the keyboard capture part of the existing app a separate executable which runs as administrator with uiAccess, I'm seeking other ideas on how to record keystrokes that work on windows for 2K, 2K3, 2K8, XP, Vista.
Edit: I know there is a security concern with just recording anything, obviously if you could do such a thing without the users notice you have your typical keystroke logger for hacking purposes. Soooooo.....
Is there a way to make journaling work, for this user, and their apps, running at the same level (or lower) and capture keystrokes? having it popup the vista security are you sure dialog would be allright, but the process cannot be marked with uiAccess (otherwise it won't interact properly with the rest of the system) and it will in 98% of cases be run by users without rights to elevate to administrator.
Even if you could, you'd probably would find Microsoft fixing that bug in the next patch. The change in Vista was intentional, and there's a clear way (uiAccess==true) to still do what you want.
We have worked around the main issues by using SetWindowsHook instead.
const HMODULE hDLL = ::GetModuleHandle(DLL_NAME);
::SetWindowsHookEx(WH_KEYBOARD_LL, myKeyboardProcCallback, hDLL, 0);
The callback now has to manage the keystroke information and translating it into usable sequences - ie don't record multiple ctrl presses when heeld down to press ctrl+key.