Dialogs without MFC?
Author
I''m sitting there happy, writing my little D3D game, when my friend IMs me and asks if there''s any way the exe I gave him to test out can run on his other video card. I think about it, and I decide that I''m going to create a little MFC dialog box that can change settings (instead of using the default keyboard, video card, etc.), and that saves settings, such as which video card to use, to a text file.
I tried to look through all these MFC articles, but it just got too confusing for me. I just want a little menu option that can create a dialog box, but I can''t figure out how!
Take a look at the DialogBoxParam() Win32 function.
Design your dialog box in the resource editor (assuming MSVC), get resource ID (e.g. IDD_CONFIGDIALOG below) and include resource.h. The call is as simple as:
DialogBoxParam( hInstance, MAKEINTRESOURCE(IDD_CONFIGDIALOG), NULL, (DLGPROC)DialogProc, (DWORD)whatever );
hInstance is the instance handle your WinMain got.
IDD_CONFIGDIALOG is the resource ID.
DialogProc is a special type of window procedure for the dialog box. You''ll get some dialog specific messages in addition to more tradition window messages.
The "whatever" above is a void pointer "context" value - put whatever you want in there. If the dialog proc is a class member function, then you could pass "this" in there.
The usual way to initialise the controls in your dialog box is in response to the WM_INITDIALOG message passed to your DialogProc.
You get WM_COMMAND messages when someone clicks on a button, WM_NOTIFY is used for more advanced notification from common controls.
GetDlgItem() lets you get the handle of a control within the dialog. All controls are treated as small windows with the dialog as their parent so you can call things like EnableWindow() on the handle you get to grey out buttons/controls etc.
You can use SendMessage() to send messages to individual controls - things like filling list boxes can be done this way.
There are plenty of other handy functions available for controls in dialogs too such as CheckRadioButton(). Take a look in/on MSDN for an exhaustive list.
EndDialog() is the way to kill a dialog when you''ve finished with it. DialogBoxParam() is a blocking function. It''ll won''t return until EndDialog is called from somewhere (e.g. in response to someone clicking your OK/CANCEL button and your DialogProc recieving that in it''s WM_COMMAND).
Call InitCommonControls() when your app starts if you need to use any of those.
--
Simon O''Connor
ex -Creative Asylum
Programmer &
Microsoft MVP
Design your dialog box in the resource editor (assuming MSVC), get resource ID (e.g. IDD_CONFIGDIALOG below) and include resource.h. The call is as simple as:
DialogBoxParam( hInstance, MAKEINTRESOURCE(IDD_CONFIGDIALOG), NULL, (DLGPROC)DialogProc, (DWORD)whatever );
hInstance is the instance handle your WinMain got.
IDD_CONFIGDIALOG is the resource ID.
DialogProc is a special type of window procedure for the dialog box. You''ll get some dialog specific messages in addition to more tradition window messages.
The "whatever" above is a void pointer "context" value - put whatever you want in there. If the dialog proc is a class member function, then you could pass "this" in there.
The usual way to initialise the controls in your dialog box is in response to the WM_INITDIALOG message passed to your DialogProc.
You get WM_COMMAND messages when someone clicks on a button, WM_NOTIFY is used for more advanced notification from common controls.
GetDlgItem() lets you get the handle of a control within the dialog. All controls are treated as small windows with the dialog as their parent so you can call things like EnableWindow() on the handle you get to grey out buttons/controls etc.
You can use SendMessage() to send messages to individual controls - things like filling list boxes can be done this way.
There are plenty of other handy functions available for controls in dialogs too such as CheckRadioButton(). Take a look in/on MSDN for an exhaustive list.
EndDialog() is the way to kill a dialog when you''ve finished with it. DialogBoxParam() is a blocking function. It''ll won''t return until EndDialog is called from somewhere (e.g. in response to someone clicking your OK/CANCEL button and your DialogProc recieving that in it''s WM_COMMAND).
Call InitCommonControls() when your app starts if you need to use any of those.
--
Simon O''Connor
ex -Creative Asylum
Programmer &
Microsoft MVP
Author
Wow, thanks! That was all I was hoping for. 
In the articles I''ve skimmed so far, I get that you create and destroy the dialog box every time it''s called. For some reason, I feel that I should design my code so that the dialog box is hidden, then shown every time it is activated. Is there a "proper" way to do it?
In the articles I''ve skimmed so far, I get that you create and destroy the dialog box every time it''s called. For some reason, I feel that I should design my code so that the dialog box is hidden, then shown every time it is activated. Is there a "proper" way to do it?
I don''t see any reason you have to destroy it all the time unless you want to save on resources. Just make sure it is modal, and that you actually hide it. Also only create once and destroy once.
If it''s just a dialog box you''re going to use for loading and storing game settings, just make it run for the life of the program, and when the user closes the dialog box, the program exits.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
