So this has been bothering me for quite a while now.
I have a program for sending keys to a window (user may select processes from a CComboBox, etc.), and I'm now trying for quite a while to figure out how it would be possible to send key-binds to a window (background !).
I know about this keybd_event function and the SendInput function. I use neither of them in my current code, as they require the window to be in the foreground.
Short said, my program can send keys and text to any (valid) window.
PostMessage(m_hwndEx, WM_CHAR, nKey, 0x00140001);
I have tried various solutions with SendMessage and PostMessage, but nothing seems to work.
Assume the program sends CTRL+SHIFT+F (as example). How would this be possible ? I would appreciate some pointer function(s) or even an external library if the 'basic' functions do not work for this matter.
I do not want the window to be in the foreground.
Related
I'm trying to use SendMessage to post mouse clicks to a background window (Chrome), which works fine, but brings the window to front after every click. Is there any way to avoid that?
Before anyone says this is a duplicate question, please make sure that the other topic actually mentions not activating the target window, because I couldn't find any.
Update: aha, hiding the window does the trick, almost. It receives simulated mouse/keyboard events as intended, and doesn't show up on screen. However, I can just barely use my own mouse to navigate around the computer, and keyboard input is completely disrupted.
So my question is, how does sending messages to a window affect other applications? Since I'm not actually simulating mouse/keyboard events, shouldn't the other windows be completely oblivious to this?
Is it possibly related to the window calling SetCapture when it receives WM_LBUTTONDOWN? And how would I avoid that, other than hooking the API call (which would be very, very ugly for such a small task)?
The default handling provided by the system (via DefWindowProc) causes windows to come to the front (when clicked on) as a response to the WM_MOUSEACTIVATE message, not WM_LBUTTONDOWN.
The fact that Chrome comes to the front in response to WM_LBUTTONDOWN suggests that it's something Chrome is specifically doing, rather than default system behaviour that you might be able to prevent in some way.
The source code to Chrome is available; I suggest you have a look at it and see if it is indeed something Chrome is doing itself. If so, the only practical way you would be able to prevent it (short of compiling your own version of Chrome) is to inject code into Chrome's process and sub-class its main window procedure.
I'm trying to write a Keyboard class that can read in the keyboard buttons. I have looked at this link - http://www.daniweb.com/software-development/cpp/code/216732/reading-scan-codes-from-the-keyboard But as stated on there, it is not very accurate for all computers (I don't know if this is even true). Therefore, my question is whats the best method in implementing my keyboard class? This will be used for Windows
Many thanks
There are three ways to read keyboard input:
By reading input from a console window as described in your link. It's true that it's hard to get this to work correctly, for starters because it's reading ANSI characters and not Unicode characters, but there are other issues. Console input/output is kind of obscure, as is the documentation for it
By handling UI events associated with a normal window. In this case you would handle the WM_KEYDOWN message in a window procedure
By going deep into the Win32 API with functions like SetWindowsHookEx. In this case you don't even need a window (normal or console), and you can read keystrokes pressed in any application or in the desktop
It's hard to suggest which one to use without knowing how you intend to use this Keyboard class.
Or to clarify this question, how can I make Windows think I hit a key, when I really didn't? I know I could possibly use SendMessage and specify the input there, but then wouldn't only my application receive it? I'd like control to the extent of all applications receiving the "fake" input. Any advice?
What you describe, faking input, is implemented by the SendInput function. Input goes to the thread which has input focus.
You can SendMessage to whatever window you want, even on other processes. You can even use HWND_BROADCAST to send it to every to-level window on the system. But is that what you really want? If you're only interested in a specific program, you can get its window's handle using FindWindow, and then send the message only to that window.
Note that if all you want to do is a simple keystrokes injection into another process, then SendInput is indeed the way to go. If you'd like to send some global keyboard shortcut it doesn't matter who has the focus. If you'd like to send the same input to more than one window using SendInput, you'll have to loop over the list of windows, and for each window first set the focus and then send the input.
Is there a way to send keystrokes to a window that is not currently selected in C++? For example, if I have a notepad window minimized and want some text to be typed in it without bringing the window to the front.
I'm using Windows 7 64-bit.
Faking input is rather hard to achieve, in full generality, without using SendInput().
Yes you can try PostMessage(), but the answer from eznme is misleading at best when it talks about SendMessage. As I, and others, seem to say many times a day here, input is posted to the message queue rather than sent to a window handle.
All that said, if you don't want to give the Notepad window input focus then it's going to be hard to get the text in there by faking. The very simple alternative that works better and is easier to use, is to find the window handle of the Notepad EDIT window and use WM_GETTEXT and WM_SETTEXT, for example, to modify its contents directly.
In fact there is an enormous multitude of functionality available once your have this window handle at your mercy!
Absolutely: Check out PostMessage() and SendMessage(), they are part of the Windows API:
http://msdn.microsoft.com/en-us/library/ms644944%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms644950%28VS.85%29.aspx
Specifically you probably want to send WM_KEYUP
http://msdn.microsoft.com/en-us/library/ms646281%28VS.85%29.aspx
I have a third party encryption library, which may create a MessageBox if key creation fails. The failure can be caused by bad random number generation or other rarities, and in most cases, trying again will result in success. My code will attempt key creation up to three times before deciding it failed.
Now, the issue is that the program may be used with automation. If a MessageBox is created during automation, it will block the process forever, because there's nobody to click the 'OK' button.
Does anyone know of a way to catch when this message box is created and automatically close it?
Anything is fair game, as long as it's not something that will make security suites angry. This means no hooking or code tunneling.
In summary, I need to catch when a MessageBox is created and close it. The MessageBox's creation is outside of my control. Modifying the code at runtime is not acceptable.
Also, I've noticed there are some other similar questions, but they don't have the same requirements.
EDIT: Additional note, I can find the message box via searching through all windows until I find one with a matching title and then send it a WM_CLOSE message, but I don't think this is a great solution. I also have no guarantee that the message box has been/will be displayed, or how long after my call it will be displayed. It could display instantly, it could display 1200 ms later, or it could not display at all.
Just before you begin the encryption process, install a WH_CBT hook, and in its callback watch for an nCode of HCBT_CREATEWND. If you get a matching class name ('#32770 (Dialog)' ?) and a matching title either return a nonzero value from the callback, or if that doesn't work post a WM_CLOSE (or a BM_CLICK to a relevant button if selecting an option is necessary). Uninstall the hook after the process for not messing with every possible dialog your application pops up.
That sounds like bad design on the part of that library. Generally any sort of utility library (like encryption) has no business invoking any kind of GUI (unless you explicitly ask it to).
Is there possibly some configuration or setting in this library that could disable its use of message boxes?
If not, I'd suggest that you might want to investigate using a different library. After all, if the designers of this library have already made this kind of poor design decision once, then there may be other unfortunate surprises lurking in there.
You can hope that it will be found by GetForegroundWindow, but this may catch other applications. The more brute force way is to iterate over all windows with EnumWindows looking for something that has a caption or text equal to this shown by the library.
I have once "remote controlled" an application by sending mouse click events to some controls. I guess you would have to do this in a separate thread that is watching for Events if a window is opened. Pretty ugly but working...
Create a new thread. If your function fails and a Message Box is opened, obtain a handle to the message box by looping through the windows (GetTopWindow, GetNextWindow) and comparing the window's process id to the one returned from GetCurrentProcessId().
Or, you can avoid all the hard work and just hook the MessageBox API with detours. It's not very hard, and if you don't want to pay for detours, you can do it manually.
Call VirtualProtect and set the memory protection at MessageBox at PAGE_EXECUTE_READWRITE
Create a naked function, and use it as a trampoline.
Create a function identical in parameters to MessageBox (this will be your hook)
Create a jump from MessageBox to your hook function.