The use of parameters to this function are the same as those of the WinLoadDlg function.

This function should not be used while pointing device capture is set (see WinSetCapture).

This function does not return until WinDismissDlg is called.

This function is equivalent to: 

WinLoadDlg (., ., ., ., ., ., dlg);
WinProcessDlg (dlg, result);
WinDestroyWindow (dlg, success);
return  (result);

and the remarks documented under these calls also apply.

If a dialog template (typically compiled using the resource compiler) references another resource (for example an icon resource for an icon static control), this function always searches for that resource in the .EXE file. If an application wishes to keep resources referenced by a dialog template in a .DLL library, these resources must be loaded by an explicit function call during the processing of the WM_INITDLG message.

This can be considered to be a customizable "read from screen" call. The caller supplies a data buffer (the pCreateParams parameter), filled with initial values. It receives a return code which indicates whether the data in the buffer has been updated and validated, or whether the end user cancelled the dialog. The end user interface is encapsulated within the dialog window. The dialog template provides a view of the current state of the data buffer, the dialog procedure defines how the user can change the data. The caller need know nothing about the details of the end user interface. It makes a single "read from screen" call and continues with its work.

Note: If a dialog box or a message box is up for a window, and the parent or owner of that window is destroyed, the code following the WinDlgBox or WinMessageBox call is executed even though the parent/owner window no longer exists. This can result in accessing data that no longer exists; especially data referenced in the window words. Therefore, it is extremely important to determine the state of your child-window procedure after this function returns. The most straightforward method for doing this is to call WinQueryWindowPtr to get a pointer to the window words. If the returned pointer is NULL, then you should exit immediately. Should this be the case, the bottom-up rule (that is, the child window gets WM_DESTROY messages first, then the parent window) still applies, and it becomes the child window procedure's responsibility to exit gracefully.