Message-handling procedures return value convention...

Message-handling procedures return value convention...

I have been interested by the adding controls to GetOpenFileName dialog thread.
Just a query for Jugoslav, Steve et al...I note that your dialog template hook procedure returns .FALSE. for all cases, including default. On the question of the general construction of message-handling procedures, I admit to not being clear on the correct convention for return values, or the actions that subsequently follow. What is the convention to observe - should one return .FALSE. if a message is NOT to be passed on to a default message handler? When should a .TRUE. value be returned? etc. etc

Message Edited by intel.software.network.support on 12-09-2005 01:34 PM

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

TRUE indicates that you handle the message and you don't want further (default) processing; thus, FALSE must be returned at least from default branch.

For handled messages, in general you return TRUE. However, in many cases, it doesn't matter. Most of the messages you normally handle in a dialog procedure (WM_COMMAND, WM_NOTIFY, WM_VSCROLL, WM_HSCROLL etc.) are not handled at all by default dialog procedure, so either TRUE or FALSE does not make the difference. On the other hand, some messages do have sensible default processing or even trigger a chain of events (DefWindowProc sends WM_SETCURSOR on WM_MOUSEMOVE, there's also important WM_NCHITTEST) so you may want to return FALSE for these as well. So, I got into habit of returning FALSE unless I specifically know I don't want any further action (for example, intercepting WM_KEYDOWN). TRUE makes difference on WM_INITDIALOG, for one.

Actually, there's a third way of returning something; it is for messages which normally require returning an integer value. Examples are WM_CTLCOLOR* (returning handle of a brush) and WM_NCHITTEST (returning a "where" index). The latter is critical: suppose you want to return HTNOWHERE (=0) (in effect, making your window irresponsive for mouse clicks); however, you can't return HTNOWHERE since it is equivalent to FALSE, and DefDlgProc will pass it on further to default processing. In that case, you have to:

CASE (WM_NCHITTEST)
   i = SetWindowLong(hDlg, DWL_MSGRESULT, HTNOWHERE)
   MyDlgProc = .TRUE.

DWL_MSGRESULT is means for returning such values.

Jugoslav

Jugoslav www.xeffort.com

Thanks, Jugoslav for your prompt and full reply.

Login to leave a comment.