NTK - Main Forum  »   callback procedure for a created DIALOG never receives "WM_INITDIALOG"

Could anyone make any suggestions why for a windows dialog created using NTK_DIALOGBOX as follows:

local bBlock := {|hWnd, nMsg , nwParam, nlParam|AppQuit(hWnd, nMsg, nwParam, nlParam)}
[...]
nRet := NTK_DIALOGBOX(NTK_GETINSTANCE(), "QUITDLG", GetMDIFrame(), bBlock)

... my "callback procedure" ("AppQuit" in the example above) NEVER receives a "WM_INITDIALOG" message?

i have had a similar issue with two dialogs so far in the same codebase i.e. the passed sub-procedures do not receive a "WM_INITIALOG" message (even though they seem to behave correctly in every other way / process other messages / display fine etc.)

i actually modified the sub-classed procedure ("AppQuit") in my example above to log every message it DOES receive at the moment the dialog is created and the results were as follows (i referred to https://wiki.winehq.org/List_Of_Windows_Messages for the nMsg meanings):

APPQUIT 24/01/2022 09:30:25: nMsg is 295 [WM_CHANGEUISTATE], nwParam is 3, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 296 [WM_UPDATEUISTATE], nwParam is 196609, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 24 [WM_SHOWWINDOW], nwParam is 1, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 70 [WM_WINDOWPOSCHANGING], nwParam is 0, nlParam is 1698036
APPQUIT 24/01/2022 09:30:25: nMsg is 134 [WM_NCACTIVATE], nwParam is 1, nlParam is 722330
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 2, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 0, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 1, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 6 [WM_ACTIVATE], nwParam is 1, nlParam is 722330
APPQUIT 24/01/2022 09:30:25: nMsg is 641 [WM_IME_SETCONTEXT], nwParam is 1, nlParam is -1073741809
APPQUIT 24/01/2022 09:30:25: nMsg is 642 [WM_IME_NOTIFY], nwParam is 2, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 7 [WM_SETFOCUS], nwParam is 525730, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 8 [WM_KILLFOCUS], nwParam is 460086, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 641 [WM_IME_SETCONTEXT], nwParam is 0, nlParam is -1073741809
APPQUIT 24/01/2022 09:30:25: nMsg is 70 [WM_WINDOWPOSCHANGING], nwParam is 0, nlParam is 1698036
APPQUIT 24/01/2022 09:30:25: nMsg is 133 [WM_NCPAINT], nwParam is 1, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 2, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 0, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 1, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 20 [WM_ERASEBKGND], nwParam is 100731696, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 310 [WM_CTLCOLORDLG], nwParam is 100731696, nlParam is 853256
APPQUIT 24/01/2022 09:30:25: nMsg is 71 [WM_WINDOWPOSCHANGED], nwParam is 0, nlParam is 1698036
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 2, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 0, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 127 [WM_GETICON], nwParam is 1, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 15 [WM_PAINT], nwParam is 0, nlParam is 0
APPQUIT 24/01/2022 09:30:25: nMsg is 312 [WM_CTLCOLORSTATIC], nwParam is 100731696, nlParam is 918846
APPQUIT 24/01/2022 09:30:25: nMsg is 312 [WM_CTLCOLORSTATIC], nwParam is 100731696, nlParam is 984476
APPQUIT 24/01/2022 09:30:25: nMsg is 312 [WM_CTLCOLORSTATIC], nwParam is 100731696, nlParam is 1115470
APPQUIT 24/01/2022 09:30:25: nMsg is 309 [WM_CTLCOLORBTN], nwParam is 100731696, nlParam is 460086
APPQUIT 24/01/2022 09:30:25: nMsg is 309 [WM_CTLCOLORBTN], nwParam is 100731696, nlParam is 984330
APPQUIT 24/01/2022 09:30:25: nMsg is 799 [???], nwParam is 1, nlParam is 0

if it helps the resource for the dialog ("QUITDLG") is defined as follows:

Quitdlg DIALOG LOADONCALL MOVEABLE DISCARDABLE 19, 31, 142, 57
CAPTION "XXX for Windows"
STYLE DS_MODALFRAME | DS_3DLOOK | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE
BEGIN
ICON "XXX", -1, 14, 10, 16, 16, WS_CHILD | WS_VISIBLE
CTEXT "Close Program?", -1, 40, 13, 86, 10, WS_CHILD | WS_VISIBLE | WS_GROUP
CONTROL "", -1, "static", SS_WHITEFRAME | WS_CHILD | WS_VISIBLE, 5, 4, 133, 27
PUSHBUTTON "&Yes", IDYES, 26, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
PUSHBUTTON "&No", IDNO, 80, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
END

Hi
Just a couple ideas/tracks:
- Does your GetMDIFrame() returns a valid handle?
- And what if you deliberately set the 3rd argument to nil/empty?
Normally, your DLG should behave modeless since it doesn't have a parent - but, my 2 cents your APPQUIT() dlgproc should then process WM_* msgs properly.
Hope this helps...
Ab.

thanks sincerely for all the suggestions / help

xbasefan - interesting, but yes the sub-classed procedure was working / receiving lots of WM_ messages: just no "WM_INITDIALOG"
Abbougaga - i did some tests on the MDI Frame window handle and it all looks valid; at the NTK_DIALOGBOX call if i just pass nothing as the parent window this did not fix the issue and the dialog appeared as if owned by the windows desktop rather than my main application window
Team NTK - thank you for making the update available (i downloaded "Latest.7z" from "https://www.ntkproject.com/ntkwip/latestchanges_v1_12_to_v1_14_pro/NTK-Pro/" and overwrote the 5 or 6 files from there into my current installation?): but that also did not fix the issue, there was still no WM_INITDIALOG message

what i DID find that fixes the issue is as follows (and this was from the helpful sample program files etc.: i looked at the "CUSTOMER_DLG" resource defined in NTKCORE\DEMOMULT.RC):

change my dialog resource definition from this -

Quitdlg DIALOG LOADONCALL MOVEABLE DISCARDABLE 19, 31, 142, 57
CAPTION "XXX for Windows"
STYLE DS_MODALFRAME | DS_3DLOOK | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE
BEGIN
ICON "XXX", -1, 14, 10, 16, 16, WS_CHILD | WS_VISIBLE
CTEXT "Close Program?", -1, 40, 13, 86, 10, WS_CHILD | WS_VISIBLE | WS_GROUP
CONTROL "", -1, "static", SS_WHITEFRAME | WS_CHILD | WS_VISIBLE, 5, 4, 133, 27
PUSHBUTTON "&Yes", IDYES, 26, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
PUSHBUTTON "&No", IDNO, 80, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
END

to this

Quitdlg DIALOG LOADONCALL MOVEABLE DISCARDABLE 19, 31, 142, 57
CAPTION "XXX for Windows"
STYLE DS_MODALFRAME | DS_3DLOOK | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_VISIBLE
FONT 11, "Arial"
BEGIN
ICON "XXX", -1, 14, 10, 16, 16, WS_CHILD | WS_VISIBLE
CTEXT "Close Program?", -1, 40, 13, 86, 10, WS_CHILD | WS_VISIBLE | WS_GROUP
CONTROL "", -1, "static", SS_WHITEFRAME | WS_CHILD | WS_VISIBLE, 5, 4, 133, 27
PUSHBUTTON "&Yes", IDYES, 26, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
PUSHBUTTON "&No", IDNO, 80, 41, 36, 14, WS_CHILD | WS_VISIBLE | WS_TABSTOP
END

in other words simply include add a "FONT" specification:
FONT 11, "Arial"

odd? almost as if asking the DIALOG to use a specific FONT somehow forces a "WM_INITDIALOG" message to be sent?

maybe someone else test if they see the same behaviour i.e. strip the "FONT" declaration out of the associated dialog resource and see if no WM_INITDIALOG is received?

PS. the only problem i have with this solution is that it does not help with at least one other case i have of the same issue where the dialog is being created using "NTK_CREATEDIALOG" (including passing the "nPointSize" and "cFontName" parameters) and then "NTK_MODALDIALOG": though i guess i could still get round this by changing this code to define the dialogs within a resource file