Unfortunately, the handle that @lparam% holds is the handle of the Cancel button, NOT the handle of the dialog box that the Cancel button and close button belong to.
It is interesting how the close button on the title bar works. It simply forwards a button click event with an ID of 2 for the Windows dialog handler to deal with. That then looks at the information it registered when the dialog was created and returns the handle of the control with an ID of 2 in the lparam%. So in the case that I described in the earlier code example where there were no controls at all in the dialog it returned a zero.
But the Windows dialog handler does not know anything about the control type with ID 2 if it finds one. The expectation is that this will be the user supplied close button but this isn't actually a requirement. This means that if you do want to do something similar to Mike and you already have a control that does not generate click events you could give that an ID of 2. A static control would be ideal and very likely to exist already in the dialog. It does not have to be an additional button in that case and a static control would suffice since all you are after is the handle of any control on that dialog.
Then you get your handle from @lparam% and use SYS "Get Parent" to get the dialog handle so you can identify and manipulate the related dialog.
Here is the modification to the earlier code.
Code: Select all
ON SYS Q%()=@msg%, @wparam% AND &FFFF, @lparam% : RETURN
REM ========================== MAIN LOOP =============================
IF Q%(1) = 2 THEN
SYS "GetParent", Q%(2) TO Q%(2)
CASE TRUE OF
WHEN Q%(2)=!dlg%: PROC_closedialog(dlg%)
WHEN Q%(2)=!dlg1%: PROC_closedialog(dlg1%)
WHEN Q%(2)=!dlg2%: PROC_closedialog(dlg2%)
PRINT Q%(0), Q%(1), Q%(2)
I would point out that this is not a recommendation but just pointing out what is possible and safe, if somewhat unconventional.
EDIT: And before someone else points it out the Static control can't have the SS_NOTIFY style or it would also close the dialog when clicked on.