C++ sends virtual key with WM_KEYDOWN on keybd_event() - c++

I would like my program to send this third party virtual key VK_ALOGIN or 0xf7 with WM_KEYDOWN.
So I try the following:
keybd_event(0xf7, 0, 0, 0);
But the program that receives this keyboard message, it receives only VK_ALOGIN, and not with WM_KEYDOWN. So is it possible that I can send 0xf7 with WM_KEYDOWN?
Please note that VK_ALOGIN is not Microsoft Virtual Key.

Receiver might be looking for keydown, as well as key up. Try sending both.
keybd_event( VK_ALOGIN, 0, 0, 0 );
keybd_event( VK_ALOGIN, 0, KEYEVENTF_KEYUP, 0 );
or
keybd_event( VK_ALOGIN, 0, KEYEVENTF_EXTENDEDKEY, 0 );
keybd_event( VK_ALOGIN, 0, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0 );
Edit: I deleted reference to SendInput because now I think it has nothing to do with the question, and I am not sure if I got SendInput right.

Related

how to simulate Ctrl + V using keybd_event () in C++

i want to paste text from clipboard to some program's textbox. so i tried to use keybd_event.
keybd_event(VK_CONTROL,0x1D, 0, 0);
keybd_event('V', 0x2F, 0, 0);
keybd_event('V', 0x2F, KEYEVENTF_KEYUP, 0);
keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_KEYUP, 0);
but this is not executed. so i tried different way
keybd_event(VK_CONTROL,0x1D, KEYEVENTF_EXTENDEDKEY, 0);
keybd_event('V', 0x2F, 0, 0);
keybd_event('V', 0x2F, KEYEVENTF_KEYUP, 0);
keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_KEYUP, 0);
so this work well. However, since then, all keyboard inputs have been entered with the ctrl key pressed.
maybe i think key-up message is not worked
how to solve this problem?
However, since then, all keyboard inputs have been entered with the
ctrl key pressed. maybe i think key-up message is not worked
You simulate right CONTROL WM_KEYDOWN but left CONTROL WM_KEYUP. So the right-hand CTRL key has not been released.
The following code will work:
keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_EXTENDEDKEY | 0, 0);
keybd_event('V', 0x2F, KEYEVENTF_EXTENDEDKEY | 0, 0);
keybd_event('V', 0x2F, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
extended-key flag (KEYEVENTF_EXTENDEDKEY)
Indicates whether the key is an extended key, such as the right-hand
ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard.
The value is 1 if it is an extended key; otherwise, it is 0.
Refer to WM_KEYUP message.
keybd_event function has been superseded. Use SendInput instead.

PostMessage / SendMessage without interference from modifier keys

I'm trying to post/send a message to some hwnd without the interference from modifier keys (ctrl, alt, shift).
Basically i want to send F1 message (without ctrl) to hwnd while im pressing ctrl (like Example 2) but with SendMessage\PostMessage.
I tried use SendInput to set up the CTRL key, post the message and set down the CTRL key back, but it fails 50% of time.
Example 1: Code with SendMessageA:
HWND hwnd = FindWindowA(0, "Notepad");
if (GetKeyState(VK_CONTROL) < -1) // if CTRL is pressed
{
keybd_event(VK_CONTROL, 0, KEYEVENTF_KEYUP, 0); // up the CTRL key
SendMessageA(hwnd, WM_KEYDOWN, VK_F1, 0); // send F1 keydown
keybd_event(VK_CONTROL, 0, 0, 0); // down the CTRL key
}
else
{
SendMessageA(hwnd, WM_KEYDOWN, VK_F1, 0); // send F1 keydown
}
Theoretically this code would solve the problem, but it sometimes sends the message with the CTRL pressed and sometimes not.
Example 2: Same code with SendInput (but these works fine)
HWND hwnd = FindWindowA(0, "Notepad");
if (GetKeyState(VK_CONTROL) < -1) // if CTRL is pressed
{
keybd_event(VK_CONTROL, 0, KEYEVENTF_KEYUP, 0); // up the CTRL key
keybd_event(VK_F1, 0, 0, 0); // send F1 keydown
keybd_event(VK_CONTROL, 0, 0, 0); // down the CTRL key back
}
else
{
keybd_event(VK_F1, 0, 0, 0); // send F1 keydown
}

Programmaticaly simulating Alt + Enter key press is not working

Here is my code:
keybd_event(VK_MENU, 0, 0, 0);
keybd_event(VK_RETURN, 0, 0, 0);
Sleep(200);
keybd_event(VK_MENU, 0, KEYEVENTF_KEYUP, 0);
keybd_event(VK_RETURN, 0, KEYEVENTF_KEYUP, 0);
The first line would press Alt
The second line would press Enter ↵ (or Return ↵),
The fourth line would release Alt,
The fifth line would release Enter ↵ (or Return ↵).
You are not setting the KEYEVENTF_EXTENDEDKEY flag to keep the keys pressed down. Change your code to:
keybd_event(VK_MENU, 0, KEYEVENTF_EXTENDEDKEY, 0);
keybd_event(VK_RETURN, 0, KEYEVENTF_EXTENDEDKEY, 0);
Sleep(200);
keybd_event(VK_MENU, 0, KEYEVENTF_KEYUP, 0);
keybd_event(VK_RETURN, 0, KEYEVENTF_KEYUP, 0);
Also you really don't need the sleep in the middle if you are just sending a Alt + Enter
You can see all of the keycodes here at the MSDN page.
Alt = VK_MENU
Left Alt = VK_LMENU
Right Alt Gr = VK_RMENU

Control LCD back light

I'd like to control LCD back light.
First, I use the code as below:
// Turn off monitor
SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2);
// Turn on monitor
SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) -1);
// Low power monitor
SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 1);
But program will hang on SendMessage()
I found the disscuss topic to solve hanging problem (Use: SendMessageTimeout function)
// Turn on monitor
SendMessageTimeout(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) -1, SMTO_ABORTIFHUNG, 100, NULL);
// Turn off monitor
SendMessageTimeout(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2, SMTO_ABORTIFHUNG, 100, NULL);
// Low power monitor
SendMessageTimeout(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 1, SMTO_ABORTIFHUNG, 100, NULL);
My problem is the program can not turn on monitor.
My process is: turn off monitor -> wait 10 seconds -> turn on monitor.
Monitor can be turned off, can not turn on monitor again after 10 seconds,
But I can see the monitor is on for a very short time after 10 seconds.
Can anyone tell me what's wrong? Thanks!
I found on Windows 8 platform, Can send a key to system to turn on LCD after turn off LCD via
SendMessageTimeout(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, (LPARAM) 2, SMTO_ABORTIFHUNG, 100, NULL);
I don't know why, but it actually work well...
INPUT in[1];
KEYBDINPUT kb;
kb.wVk = VK_CONTROL;
in[0].type = INPUT_KEYBOARD;
in[0].ki = kb;
SendInput(1, in, sizeof(in));

Win32 SetForegroundWindow unreliable

I have a rather complex series of applications which depend on the ability to switch applications in the foreground.
My problem is, every 5 or 6 times of switching the applications in the foreground, it simply fails to bring the application forward. GetLastError does not report any issues. Often times I see the correct application flash in the foreground for a moment then the previous application is visible.
I have a Manager application which I have source for, it spawns and controls about 4 applications which I do not have source for. one of the applications it spawns/controls is also a manager which spawns/controls about 5 applications.
This is a sort of kiosk design so the user wont even have a keyboard or mouse, just a touch screen.
I have tried every combination of the Win32 calls to control them I am just out of ideas.
My first attempt was:
SetWindowPos(hApp, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetWindowPos(hApp, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
My second attempt was:
SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);
my third attempt:
DWORD dwThreadID = GetWindowThreadProcessId(hApp, NULL);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);
SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);
my forth attempt:
DWORD dwThreadID = GetWindowThreadProcessId(hApp, NULL);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);
SetWindowPos(hApp, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetWindowPos(hApp, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);
I feel like I am missing an important gotcha when it comes to window switching. I know that only the foreground process can switch windows around but as my main Manager program is spawning and starting all the other processes which I need to control, I feel like it should be capable of moving these windows around. Any suggestions or advice is appreciated.
I was having the same issue and I didn't want to mess up with threads. On experimenting I observed a simple hack to make SetForegroundWindow() work in the expected manner. Here is what I did:
Minimize the window if its not already minimized
Restore the minimized window
Call SetForegroundWindow(), and your window will be on top
Your AttachThreadInput() hack is (I think) a known way to defeat the focus stealing counter-measures in Windows. You are using the wrong handle though, you want to attach to the thread that currently has the focus. Which won't be hApp, you wouldn't need this code otherwise.
Use GetForegroundWindow() to get the handle to the window with the focus.
AttachThreadInput(
GetWindowThreadProcessId(GetForegroundWindow(), NULL),
GetCurrentThreadId(), TRUE
);
Although I think the 2nd argument needs to be thread ID of hApp. Because you don't want to shove your own window if I understood correctly. Not sure if that can work.
The easiest solution in C# to bring a window in the foreground:
Once you have the handle for the window, you can simply call:
SetWindowPos(handle, new IntPtr(0), 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW);
ShowWindow(handle, 5);
SetForegroundWindow(handle);
// If it is minimized, show the window
if (IsIconic(handle))
{
ShowWindow(handle, 3);
}
where
const int SWP_NOMOVE = 0x0002;
const int SWP_NOSIZE = 0x0001;
const int SWP_SHOWWINDOW = 0x0040;
Some windows are locked with setforeground(...),
you need to unlock them. This sequence is useful with any window:
HWND needTopWindow=FindWindow(TEXT("classname"), TEXT("window name"));
the classname and window name you can retrieve with ranorexspy from e.g.
nanoware.cz
if(!::IsWindow(needTopWindow)) return;
BYTE keyState[256] = {0};
//to unlock SetForegroundWindow we need to imitate Alt pressing
if(::GetKeyboardState((LPBYTE)&keyState))
{
if(!(keyState[VK_MENU] & 0x80))
{
::keybd_event(VK_MENU, 0, KEYEVENTF_EXTENDEDKEY | 0, 0);
}
}
::SetForegroundWindow(needTopWindow);
if(::GetKeyboardState((LPBYTE)&keyState))
{
if(!(keyState[VK_MENU] & 0x80))
{
::keybd_event(VK_MENU, 0, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
}
}
DWORD dwThreadID = GetWindowThreadProcessId(needTopWindow, NULL);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);
SetWindowPos(needTopWindow, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetWindowPos(needTopWindow, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetForegroundWindow(needTopWindow);
SetActiveWindow(needTopWindow);
SetFocus(needTopWindow);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);
We had a similar problem a couple of years ago. We could solve it by the following function call:
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_UPDATEINIFILE);
Give it a try. See the documentation here.
Try pushing the other application windows to the background first.
Also its a bit strange that you use SetWindowPos (SWP) to push a window to the foreground then push it out of the forgreound before using SetForegroundWindow to bring it back foward. Personally I've always used the SWP method without any issue ... but I've always pushed the other windows to the bottom as well.
You also need to consider the chances of window being minimized. If the window or various application are minimized then SetForegroundWindow(hApp) won't work. To be safe use ShowWindow(hApp, 9); I prefer value 9. Have a look at its documentation and choose which you find fit for you.