|
Directly take the output from findFileData.cFileName.
The problem exists in your convertWCharArrayToString().
std::cout <<fileNumber <<":" <<findFileData.cFileName <<std::endl;
|
|
|
|
|
well still the same.. if i put the exe file in C:/ and run it it shows the files and folders in C:/ but it does not going in further into the folders and get the file list....
The program i been working have to get the entire files in the subfolders.. since i am creating a anti-worm system...
thanks
|
|
|
|
|
Where do you have problem exactly?FindFirstFile is easy to use?
Of one Essence is the human race
thus has Creation put the base
One Limb impacted is sufficient
For all Others to feel the Mace
(Saadi )
|
|
|
|
|
You have to recursively call and iterate each Folders from the output if findFileData.dwFileAttributes is FILE_ATTRIBUTE_DIRECTORY.
Try that.
|
|
|
|
|
I want to hook a mouse events of a specified window. So, i install a WH_MOUSE hook callback procedure for that thread.
If i didn't hook that message, the thread would show a pop menu when it received a right button message.
After i hooked that thread, windows would call my callback procedure when such event occurred, but the original window's message handler would be called, too. But i want to hold such message to make the original window will not receive such message. I use global hooks but check the process id like:
LRESULT CALLBACK MouseHookProcedure(int nCode, WPARAM wParam, LPARAM lParam)
{
if(0 > nCode)
return CallNextHookEx(g_hPreviousMouseHook, nCode, wParam, lParam);
MOUSEHOOKSTRUCT *pMouseHooksStruct = (MOUSEHOOKSTRUCT *) lParam;
DWORD process_id;
GetWindowThreadProcessId(pMouseHooksStruct->hwnd,&process_id);
if(process_id==target_process_id){
.... my process
return 1;
}
return CallNextHookEx(g_hPreviousMouseHook, nCode, wParam, lParam);
}
that, target_process_id is stored in the shared segment block, im sure its ok.
How to fix such a problem?
Regards.
|
|
|
|
|
what happens if you dont call CallNextHookEx in the return statement ? (ie remove the CallNextHookEx and return [something else])
... it occurs to me that is what is propagating the message to the next handler.
'g'
|
|
|
|
|
you means the last? if the message is in the window handle i want to handle, the last CallNextHookEx will not be called.
|
|
|
|
|
Are you sure your hook is being called?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
of courese im sure. i place a messagebox at the if block, the messagebox will display there.
|
|
|
|
|
And does your process-id comparison become TRUE at the right times?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
yes, im sure. because i instore the target process' process id in a shared segment. And i also has placed a messagebox at that if block for testing.
|
|
|
|
|
Well, the documentation says that returning a non-zero value MIGHT prevent the system from letting the message go on his marry way. So i guess there's no assurance. How about altering the MOUSEHOOKSTRUCT , for example, setting hwnd to NULL before you return?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
No. My target test program is a simple mfc dialog with a tray icon, when you right-click the tray there will be a popup menu display. I want to hook the mouse messages so that the menu will not appear on the screen. No matter i return which value or change the hwnd member of MOUSEHOOKSTRUCT to NULL, the menu will always display, the difference is that, this menu will not receive messages any more.
|
|
|
|
|
Ah, you won't get mouseclick events from an icon clicked on the tray, that works differently. See here[^]. You can specify what message your application wants to receive if the icon gets clicked on the tray. You should probably look for that message instead of mouseclicks. You should have said that earlier.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
but, if so, i want to hook such message, what should i do?
|
|
|
|
|
Well, first you need to determine what that message is, as said, the application can TELL the shell what it wants to receive so bascily it can be anything. Try using spy++, maybe it helps, maybe it does not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
ok. i used spy++ and found the tray icon always receives TB_GETBUTTONINFO message. and i googled found someone said i almost couldn't hook that message in its owner window's message loop, because TB_GETBUTTONINFO is internal messages in controls. right?
If so, maybe i only can hook its owner window's main message callback procedure. any idea?
|
|
|
|
|
I'm not sure but i think you misunderstood something, what i meant is the message that is received by the application if the tray icon is clicked. Usually this works something like:
-the application uses Shell_NotifyIcon[^] to install an icon on the tray, specifying -for example- WM_USER or WM_APP or some other message it wants to receive when the icon is clicked on
-the user right-clicks the icon on the tray, the application receives the message it specified when using Shell_NotifyIcon along with some other information telling it that the icon was right-clicked (you can look this up in the documentatin if you like), the message is targeted at the window that was also specified when Shell_NotifyIcon was used.
-the application displays the popup menu at the mouse cursor's position and handles the user's menu selection
So basicly, i gess what you want is to catch the message fed to Shell_NotifyIcon.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
You are calling CallNextHookEx()[^] in both the case i.e. nCode > 0 or nCode < 0; You may return a nonzero value to prevent the system from passing the message to the target window procedure from your handler. Even have a look at this[^].
|
|
|
|
|
But here he does exactly that, not call CallNextHookEx and return non-zero:
if(process_id==target_process_id){
.... my process
return 1;
}
Am i missing something?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
Sorry ! I missed it !
It's my coffee time !
|
|
|
|
|
you can see, if nCode>0, to the target process(other processes are not what i want to deal with) the flow will enter the if block, so the second CallNextHookEx will never be called.
|
|
|
|
|
Does GetWindowThreadProcessId return proper process id ? The only possibility is your if(process_id==target_process_id) is not satisfying. Check whether you've defined the shared section properly, and even look for values of target_process_id and process_id by debug printing them.
|
|
|
|
|
yes, target_process_id do be defined in a shared segment:
#pragma data_seg (".SHARED")
HHOOK g_hPreviousMouseHook = 0;
HHOOK g_hPreviousWinProcHook = 0;
HINSTANCE g_hInstance = 0;
HWND g_hMinimizedWindowList[ARRAY_SIZE] = {0};
int g_iMinimizedWindowCount = 0;
DWORD target_process_id = 0;
#pragma data_seg()
#pragma comment(linker, "/SECTION:.SHARED,RWS")
Malli_S, this code slice is copied from your tutor article http://www.codeproject.com/KB/system/TrayMe.aspx. Im trying your demo project today.
|
|
|
|
|
You through with your issue ?
[Delegates] [Virtual Desktop] [Tray Me !]
-Malli...!
|
|
|
|