Unless window style WS_VISIBLE is specified for the dialog window in the DIALOG statement within the dialog template, the dialog window is created as an invisible window.
The dialog window owner may be modified, in order to ensure acceptable results if it is later processed as a modal dialog using the WinProcessDlg or WinGetDlgMsg functions. A search is made up the parent hierarchy, starting at the window specified by the hwndOwner parameter, until a child of the window specified by the hwndParent is found. If such a window exists, it is made the actual owner of the dialog. If no such window exists the actual owner of the dialog is set to NULLHANDLE.
This function returns immediately after creating the dialog window. A WM_INITDLG (Default Dialogs) message is sent to the dialog procedure before this function returns.
This function should not be used while pointing device capture is set (see WinSetCapture).
As each of the controls defined within the template of this dialog window is created during the processing of this function, the dialog procedure may receive various control notifications before this function returns.
A dialog window can be destroyed with the WinDestroyWindow function.
Because windows are created from the template, strings in the template are processed with WinSubstituteStrings. Any resultant WM_SUBSTITUTESTRING messages are sent to the dialog procedure before this function returns.
When the child windows of the dialog are created, the WinSubstituteStrings function is used to allow the child windows to perform text substitutions in their window text. If any of the child window text strings contain the percent (%) substitution character, there is an upper limit of 256 on the length of the text string, after it is returned from the substitution.
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.
Note: In general, it is better to create the dialog window invisible as this allows for optimization. In particular, an experienced user can type ahead, anticipating the processing in the dialog window.
In this instance, there may be no need to display the dialog window at all, as the user might have finished the interaction before the window can be displayed.
This is in fact how the WinProcessDlg function works; it does not display the dialog window while there are still WM_CHAR messages in the input queue, but allows these to be processed first.