Is there a way to make sure the window runs it's procedure and handles it's messages even if it is inactive or minimized?
Thanks in advance.
Printable View
Is there a way to make sure the window runs it's procedure and handles it's messages even if it is inactive or minimized?
Thanks in advance.
At the WinAPI level the message dispatcher (GetMessage(), TranslateMessage(), DispatchMessage() etc.) should take care of that naturally.
If there's a problem can you post the relevent code sections?
If a window has been created it will still receive messages while inactive, minimised, hidden.
here's some part of the code (from the window procedure)
as you can see, it is supposed to change the coordinates of the cursor using keyboard input. It manages the job when it is active, but when it is minimized, it won't happen.Code:
case WM_KEYDOWN:
switch(wParam)
{
case VK_UP:
pCur.y=pCur.y-10; //I declared pCur as a static POINT//
SetCursorPos(pCur.x,pCur.y);
break;
case VK_DOWN:
pCur.y=pCur.y+10;
SetCursorPos(pCur.x,pCur.y);
break;
case VK_LEFT:
pCur.x=pCur.x-10;
SetCursorPos(pCur.x,pCur.y);
break;
case VK_RIGHT:
pCur.x=pCur.x+10;
SetCursorPos(pCur.x,pCur.y);
break;
}
After i posted the question, i suddenly realised that the problem wasn't the messsages, it was about the keyboard focus. Sorry about the misinformation. Anyway, is there a way i can keep the program working, even when it is minimized?
when the window is minimised it wont have keyboard focus, you can use a hook to capture the keyboard information SetWindowsHookEx Function, Using Hooks
Yes, it is about keyboard focus. Only the foreground window can receive keyboard input.
Unfortunately making this work from the background gets just a little complex. You will need to dabble in DLL injection and global hooks, which is not the easiest of programming. Basically you need to create a DLL that contains a global keyboard hook which will intercept keystrokes and deal with them.
LowLevelKeyboardProc Callback Function (Windows)
Low level keyboard hooks don't require dlls:
For example (a to exit):Quote:
Originally Posted by From your link
Code:#include <windows.h>
LRESULT CALLBACK LLKeyProc(int action, WPARAM wParam, LPARAM lParam)
{
if(action == HC_ACTION)
{
PKBDLLHOOKSTRUCT pKey = (PKBDLLHOOKSTRUCT)lParam;
printf("Got key press %x\n", pKey->vkCode);
if(pKey->vkCode == 'a')
{
PostQuitMessage(0);
}
}
return CallNextHookEx(NULL, action, wParam, lParam);
}
int main(int, char**)
{
HHOOK hook = SetWindowsHookEx(WH_KEYBOARD_LL, &LLKeyProc, NULL, 0);
if(hook)
{
while(WaitMessage())
{
MSG msg = {0};
while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if(msg.message == WM_QUIT)
{
goto exit;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
exit:
UnhookWindowsHookEx(hook);
}
return 0;
}
However... if you scroll to the bottom of that page and look... the low level keyboard hook, which is what our friend needs is a global hook, requiring that it be in a DLL...
Also from the same page...
(Empahsis mine...)Quote:
SetWindowsHookEx can be used to inject a DLL into another process. A 32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL cannot be injected into a 32-bit process. If an application requires the use of hooks in other processes, it is required that a 32-bit application call SetWindowsHookEx to inject a 32-bit DLL into 32-bit processes, and a 64-bit application call SetWindowsHookEx to inject a 64-bit DLL into 64-bit processes. The 32-bit and 64-bit DLLs must have different names.
I ran into this with a mouse hook some years back. Couldn't get the thing to work for the life or me... build a DLL and set the hook from the DLL and away it goes.
yes, msdn saysQuote:
You must place a global hook procedure in a DLL separate from the application installing the hook procedure. The installing application must have the handle to the DLL module before it can install the hook procedure. To retrieve a handle to the DLL module, call the LoadLibrary function with the name of the DLL. After you have obtained the handle, you can call the GetProcAddress function to retrieve a pointer to the hook procedure. Finally, use SetWindowsHookEx to install the hook procedure address in the appropriate hook chain. SetWindowsHookEx passes the module handle, a pointer to the hook-procedure entry point, and 0 for the thread identifier, indicating that the hook procedure should be associated with all threads in the same desktop as the calling thread.
As an example of form.... there's the DLL from that mouse hook project...
Load the DLL... call the SetMHook function and the DLL is then injected into each process. There just wasn't any other way to do it.Code:#define WIN32_LEAN_AND_MEAN
#define _WIN32_WINNT 0x400
#pragma comment(linker, "/heap:128")
#define MMAPI __declspec(dllexport)
#include <windows.h>
/////////////////////////////////////////////////////////////////
// Handle double click
//
BOOL RevButtons = 0;
void SendClick(void)
{ if (!RevButtons)
{ mouse_event(MOUSEEVENTF_LEFTDOWN,0,0,0,0);
mouse_event(MOUSEEVENTF_LEFTUP,0,0,0,0);
mouse_event(MOUSEEVENTF_LEFTDOWN,0,0,0,0);
mouse_event(MOUSEEVENTF_LEFTUP,0,0,0,0); }
else
{ mouse_event(MOUSEEVENTF_RIGHTDOWN,0,0,0,0);
mouse_event(MOUSEEVENTF_RIGHTUP,0,0,0,0);
mouse_event(MOUSEEVENTF_RIGHTDOWN,0,0,0,0);
mouse_event(MOUSEEVENTF_RIGHTUP,0,0,0,0); } }
/////////////////////////////////////////////////////////////////
// Mouse mod process
//
int lastdir = 1; // wheel tracker
BOOL mbutton = 0; // settings
BOOL hysterisis = 0;
HHOOK mmhook = NULL; // mouse hook handle
PMSLLHOOKSTRUCT mhs;
MMAPI LRESULT CALLBACK MouseTracker(int code, WPARAM wparm, LPARAM lparm)
{ if (code < 0)
return CallNextHookEx(mmhook,code,wparm,lparm);
// get struct address
mhs = (PMSLLHOOKSTRUCT)lparm;
// process the message
switch (wparm)
{ case WM_MBUTTONDOWN : // replace with lbutton dblclick
{ if (mbutton)
{ SendClick();
return 1; }
break; }
case WM_MBUTTONUP :
{ if (mbutton)
{ return 1; }
break; }
case WM_MOUSEWHEEL : // drop 1 msg on wheel reverses
{ if (hysterisis)
if (((lastdir < 0) && ((int)mhs->mouseData > 0)) ||
((lastdir > 0) && ((int)mhs->mouseData < 0)))
{ lastdir = (int)mhs->mouseData;
return 1; } } }
return CallNextHookEx(mmhook,code,wparm,lparm); }
/////////////////////////////////////////////////////////////////
// Enable features
//
MMAPI void WINAPI SetMButton(BOOL dblclk)
{ mbutton = (dblclk & 1); }
MMAPI void WINAPI SetMWheel(BOOL rollback)
{ hysterisis = (rollback & 1); }
/////////////////////////////////////////////////////////////////
// Set the windows hook
// if goforit = 1 hook is set, 0 to release
// Returns hook status 1 = active, 0 = not
//
HINSTANCE hdll; // dll handle
MMAPI BOOL WINAPI SetMHook(BOOL goforit)
{ if (goforit)
{ if (mmhook)
return 1;
mmhook = SetWindowsHookEx(WH_MOUSE_LL,&MouseTracker,hdll,0);
RevButtons = GetSystemMetrics(SM_SWAPBUTTON); }
else
{ if (mmhook)
{ if (UnhookWindowsHookEx(mmhook))
mmhook = NULL; } }
return (mmhook != NULL); }
/////////////////////////////////////////////////////////////////
// DLL entry point
//
BOOL APIENTRY DllMain(HINSTANCE hinst, DWORD reason, LPVOID reserved)
{ if (reason == DLL_PROCESS_ATTACH)
hdll = hinst;
return 1; }
Can you people not compile and run code that's in front of you? Where's the required dll? Does it not work? Can't you use Process Explorer and verify that even if you use a dll it never gets injected anywhere? Can't you put two and two together and figure, 'Gee, if the OS is gonna call me in my own process context (which doesn't happen with the other global hooks, only the LL ones), what would be the point of it injecting stuff into another process?'
EDIT:
Now I find it, paragraph under the one I quoted in my last post:
Quote:
Originally Posted by msdn
Ah, smug mode. I can't hang around here saving your necks all day, I think I'll make a start on that ironing.Quote:
Originally Posted by msdn
Proof, as if it were needed - Imageshack - 34435171.png
Adeyblue... the guys who wrote the Operating System disagree with you... what can I say?
Last week there was a topic on key loggers. How did it work?
It was also a console program that triggered virus scanners...
It was using GetAsyncKeyState() in a loop... probably pounding the system in the process.
Maybe if you tell me exactly what you're trying to accomplish ...
Interresting project... MouseKeys have been a standard windows feature (since Win98) under "accessibility", so we know it can be done.
You will need to make the DLL as I showed you for that. You will need to handle keybd_event notices at that level, but they're pretty easy.
You'll also need a small "mother" program to keep the DLL loaded. Usually these small programs show an icon in the system tray so you can get to any settings... such as which keys do what or how fast the mouse moves etc. So this will need to turn itself into a Windows API program.
The good news is that once you get the hang of setting the hook it's pretty easy going from there...
Wellll... you could try LoadLibrary()
Since you're working at winapi level, you really should get a copy of the Windows SDK... It's a near total disclosure of Windows API functions and information.
You might also want to pay a visit to the Forger's Win API tutorial for a good start in GUI mode programming.
Well technically it's the people who wrote the documentation who disagrees with him. And in this case the docs are wrong.
The documentation for SetWindowsHookEx says
"All global hook functions must be in libraries."
but they should actually say something like
"All global hook functions, except the low level hooks, must be in libraries."
See How to set a Windows hook in Visual C# .NET for reference
Quote:
Low-level hook procedures are called on the thread that installed the hook. Low-level hooks do not require that the hook procedure be implemented in a DLL.
Thank you, Common Tater, for your respond to my request.
Thing I don't get, for the life of me... what's so wrong with putting the SetWindowsHook call in a DLL ... you're going to have to have a DLL anyway so you can catch the key/mouse/window events by injecting it into each process... so what's the problem?
Seems to me this is mostly argument for argument's sake...
The ignorance of this threads content is legendaryQuote:
you're going to have to have a DLL anyway so you can catch the key/mouse/window events by injecting it into each process
Discussing keyloggers in this forum is against the forum guidelines. Before I close this thread my main question is in order to create a 'virtual mouse' why do you need a window that is minimized, hidden, or otherwise invisible to the user to receive keyboard input? Windows was designed so that one window would have the keyboard focus. You should have a very good reason for going against this design. Low level keyboard hooks are probably not the answer here but perhaps a re-design is. Just b/c the low level keyboard hook works does not mean you should be using that in this situation.
Quote:
Last week there was a topic on key loggers. How did it work?
So far no illegal activity has been discussed here and since the guidelines do not clearly call out keyloggers I will use my best judgement here and leave the thread open.Quote:
6. Messages relating to cracking, (erroneously called "hacking" by many), copyright violations, or other illegal activities will be deleted. Due to the overlapping boundaries of code with malicious intent, and other legitimate uses of it, the moderators will assess each potential infraction on a case by case basis.
Hey Ace... We aren't discussing keyloggers... the OP is trying to make a key-mouse tool similar to the Windows tool that lets you manipulate the mouse from your keyboard arrow keys. It's a perfectly legit project... and don't worry, I'm not about to help anyone write anything I consider suspicious. The DLL I posted demonstrates how to inject a DLL and catch mouse messages to activate the wheel button for double clicks. Again a perfectly legit use of code and time.
The keylogger question came up because the OP is getting a dump truck full of conflicting information and is trying to weed his way through it. I don't envy the guy, it shure has been heeped on nice and deep. I'm just trying to help him understand the problem... I'm not sure what the others are hoping to accomplish...
I apologize if this appears a borderline discussion... However you can rest assured I would not be in it if I thought we were creating a monster.
I ascertained that from reading through the thread a second time which is why I'm leaving it open.Quote:
Hey Ace... We aren't discussing keyloggers...
The reason why I would avoid dll injection unless it was absolutely required (and I don't think it is for this kind of application) is that bugs/mistakes in the dll risk taking down more than just your own application if it crashes.
But properly coded there's nothing wrong with using dlls, and I'm sorry if I made it seem as such.