I had added this code in order to trace exactly the window messages that i'm getting. However, as you all can notice, the log file will contains a meaningless content as the below:
Well, the messages are all equates specified in the various windows includes, so if you are looking for, for example 'WM_CREATE', you won't get 'WM_CREATE, but rather the number assigned to WM_CREATE. So you'll need a switch to output WM_CREATE to your file when that message (or any other) is received.
Second, there are usually two numbers packaged in the WPARAM. You need the HIWORD() and LOWORD macros to seperate them out. The LPARAM is usually a pointer, and when it is there isn't any HIWORD or LOWORD to that one.
Personally, I'd use the text output functions, rather than the way you are doing it with fwrite.
Thx for your update..
However, from where could I know which number corresponds to WM_CREATE for example!!!
I know that I still need a switch to output the exact message identifier rather than its corresponding number. But I need the full list of those messages and their assigned numbers.
Regarding the WPARAM and LPARAM, actually I don't need to know their values in the message log file. But when I know the message name, I will be able to know the HIWORD and the LOWORD since their meaning and values will change with the changing of the corresponding message.
Do you have some utility to scan directories for names? That's how I came up with this from winuser.h (which makes sense - that's where a large number of Win Api functions for the user interface are located)...
I had found this file as you specified, however, I have some questions about some defined pre-processor and their values. The below values stand for which windows version?
1 2 3 4
WINVER >= 0x0500 or 0x0400 or 0x0600
_WIN32_WCE
_WIN32_WINNT >= 0x0500 or 0x0501 or 0x0600
_WIN32_WINDOWS > 0x0400
Moreover, I found that there a long list of numbers that are missing while assigning numbers to each message like:
As for the missing numbers, some of the windows messages are older and no longer used, others are reserved for system use only; there are probably more reasons but those two are the major ones.
I have a question:
does every control (edit, button, combobox, ...) has its window procedure handle ?
I am sending a WM_SETTEXT message to an edit box and then i'm not able to find it in the list of messages that i'm printing into the file as mentioned above.. please note that the messages i'm listing are the messages of a form containing that edit box.
Moreover, i would like to know how to set the focus for this edit box. i tried to send message with WM_SETFOCUS but it didnt work as well
any body to answer me guysssssss ??!!!!!!!!!
Furthermore, from where can i get a document that illustrate the flow of messages from creating any window and then creating its control items till the window is read for user input or interaction. I need to know those in order to manipulate the control items (modify their position, size, behavior, ...) before they being created and in order to do other needed validation.
I think you might be over-doing it with outputting messages ahbazzi! Yes, yes, messages are really important - its how Windows works. But the fact is that there are just too many to really accomplish what you seem to be trying.
Also, keep in mind that your main window's WndProc seems to be where you are executing output statements, and the only messages you will catch there are messages pertaining to your main program window. If you you SendMessage() a WM_SETFOCUS to an edit control which is a child of your main program window, that message will not pass through your main program window's window procedure, but rather will go to the edit control's window procedure, and that window procedure isn't in your app, but rather within Windows. Also, you may have better luck using SetFocus( handle of window you want to have focus ) instead of SendMessage()'ing WM_SETFOCUS. Read up on the SetFocus() Api Function.
Having said that, if you really insist on wanting to see the messages sent to child controls, then you will have to subclass the control using SetWindowLong(). In that way you would have a 'hook' of sorts into the window procedure for the control in Windows itself. You would create a Window Procedure for the child window control in your app, and Windows would call it for you.
Further, keep in mind the important and sometimes confusing distinction between Windows Messages, and child window control Notification Messages.
ahbazzi if you want to see what window messages are being sent then I suggest you get the following.
www.softpedia.com › Windows › Security › Security Related
24 Mar 2010 – Download Winspector - An application that allows you to look at the messages being sent in the system.