Windows Messages

[Cliff Nichols]

I am working on an INC for Windows messages (Basically translates wParam and lParam into readable statements for logging, or looking up possible errors etc.

The deeper I get though the more I find Docs only show 1 parameter or states that it takes no parameters.

In cases like these is it safe to consider those values to be zero? or some value like Invalid_Handle? or something else I would have to pass if I were doing a SendMessage????

I am also starting to see why no one (that I have found yet) has done this as the few messages I have documented in my code is really monotonous compared to looking up Messages in the Docs only when I use them

[Michael Mattias]

>In cases like these is it safe to consider those values to be zero?

AFAIK, for messages you send when a param is 'unused' the doc says make it zero and if not you can make it anything you'd like.

Example?

[Cliff Nichols]

Example:

WM_DEVMODECHANGE
lpszDev = (LPCTSTR) lParam; // address of device name

No mention about what to set wParam to so I would assume it to be zero? (have not tested yet)

and then there are ones like WM_SYSCOLORCHANGE that the docs do not state if anything is returned, or what to expect if there is a return?

and of course my favorite (insert sarcasm here)

WM_QUERYENDSESSION
nSource = (UINT) wParam; // source of end-session request
fLogOff = lParam // logoff flag

where the parameters are described as

nSource

Reserved for future use.

fLogOff

Value of lParam. Indicates whether the user is logging off or shutting down the system. Supported values include: ENDSESSION_LOGOFF.

Which is fine, but if ENDSESSION_LOGOFF is one of the values, what are the other values????

I know I have a lot of research to do, and comparisons with MSDN yet to go

[Cliff Nichols]

One other thing I am noticing is that most messages should return some value if processed. In most cases, since the returned value should be zero, am I getting away with these calls to my callback only because I do not return a value, so it is assumed zero?

If this is the case then examples I see all the time for callbacks do not return a value, and should really return a value for readability and maintainability ????

[Fred Harris]

I don't use DDT so I'm not sure what goes on there, but with SDK style I try to be extremely careful about returning exactly what the docs for a message specify. Most messages return 0 when processed, as I'm sure you know. However, a number of them do return other values. The ones that come immediately to mind for me are WM_CREATE for failure (-1 I believe), and WM_CTLCOLORSTATIC (which I believe requires a return of a HBRUSH). There are others though, of course.

One thing, if you are sending messages, you need to use the macros that combine two 16 bit values into a 32 bit value, i.e., wParam and lParam.

[Michael Mattias]

LRESULT CALLBACK WindowProc(
  HWND hwnd,          // handle to window
  WM_QUERYENDSESSION, // the message to send
  WPARAM wParam,      // not used
  LPARAM lParam       // logoff option
);

LRESULT CALLBACK WindowProc(
  HWND hwnd,       // handle to window
  UINT uMsg,       // WM_DEVMODECHANGE
  WPARAM wParam,   // not used
  LPARAM lParam    // device name (LPCTSTR)
);

Neither one of these messages is sent by an application program, so "what to set the unused parameter to" is immaterial.

[José Roca]

Which is fine, but if ENDSESSION_LOGOFF is one of the values, what are the other values????

Don't know which help file are you using (maybe one many years old?), but both the Platform SDK Help and MSDN list the following:

ENDSESSION_CLOSEAPP
0x00000001

ENDSESSION_CRITICAL
0x40000000

ENDSESSION_LOGOFF
0x80000000

[Dominic Mitchell]

LRESULT CALLBACK WindowProc(
HWND hwnd, // handle to window
WM_QUERYENDSESSION, // the message to send
WPARAM wParam, // not used
LPARAM lParam // logoff option
);

LRESULT CALLBACK WindowProc(
HWND hwnd, // handle to window
UINT uMsg, // WM_DEVMODECHANGE
WPARAM wParam, // not used
LPARAM lParam // device name (LPCTSTR)
);

Neither one of these messages is sent by an application program, so "what to set the unused parameter to" is immaterial.

How did you come to that conclusion?
I am afraid your reply is wrong for both of these messages.

In the case of WM_QUERYENDSESSION, a programmer sends this message from the window procedure of the
MDI Frame to MDI Child windows when the application is shutting down. The WM_CLOSE message can also
be used for this, but WM_QUERYENDSESSION is better because of the information carried by the lParam
parameter.

In the case of WM_DEVICEMODECHANGE, when your application changes the settings a device such as the
printer, who do you think is responsible for broadcasting the changes to all top-level windows?
Your app, by doing something like this

 
SendMessageTimeout %HWND_BROADCAST, %WM_DEVMODECHANGE, 0, BYVAL VARPTR(szPrinterName), %SMTO_NORMAL, 1000, BYVAL %NULL

Many messages that you think are not sent by applications usually are.

On a related matter, a poster recently said that we don't know what DefWindowProc does. It was made by a DDT'er(the blind)
so I let it slide. Nothing could be further from the truth. There are messages that let us query DefWindowProc for useful
information about a window. Unfortunately, folks who are weaned on DDT don't know this. And those are messages that you
would not normally think are sent by an application.
For example, WM_NCCALCSIZE and WM_NCHITTEST.

...so "what to set the unused parameter to" is immaterial.

Really bad advice, in my opinion. And the same goes for return values. Ignore the documentation at your peril, because
if Microsoft were to introduce a new message in response to a particular message, you would be in trouble if the return
value or parameters became relevant. The introduction of the WM_CONTEXTMENU message is one example that caused grief.

[Cliff Nichols]

Thank you Dominic,

I was really starting to wonder if my question was more along the lines of going to Vegas, thinking I had a "System" to beat the "House" and rolling the dice knowing that 0 = beat the house....other = lose unless I know the value would be the roll of the die


That said, I am more of a purist mind when told to do something (like understanding why to use 3.1415926535897932384626433832795 instead of just 3.14 in mathematical areas (I learned 3.14 may work in cases, when pi is NOT 3.14, but thats another issue)

Rules are RULES!!! and some can be (and will be bent), but when they break, if you do not know why they break you can not possibly find where/what/when/how they broke

Currently I guess my best avenue when I have questions as to what to pass is to either pass 0, or something purposely invalid (or at least my best guess given the documentation given for the function being called) and DEFINITELY at least comment points where I took my best "Guesstimation" and could be wrong (so it can be corrected in the future)