That's the way to go if you're using MFC, but since this is a non-MFC forum, here's the strictly WinAPI approach:
Code:
#include <windows.h>
#include "resource.h"
// +----------------------------------------------------------------------------
// | -DialogProc()-
// | This is the callback function that processes the messages sent to our
// | dialog box. Most everything of consequence in such a program is either
// | done here or called from here.
// +----------------------------------------------------------------------------
BOOL CALLBACK DialogProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
// check message type
switch (uMsg)
{
case WM_COMMAND:
// here's where you would process commands sent to the dialog box
switch (LOWORD(wParam))
{
case IDOK:
// OK button clicked - perform data validation and such here
EndDialog(hWnd, TRUE);
break;
case IDCANCEL:
// Cancel button clicked
EndDialog(hWnd, FALSE);
break;
// process messages from additional controls here
}
break;
case WM_INITDIALOG:
// perform any necessary initialization here - return FALSE if you
// set the focus to a control yourself, otherwise just break and
// allow the function to return TRUE to indicate that the keyboard
// focus should be set automatically
break;
default:
// return zero if we do not process this message
return FALSE;
}
// return nonzero if we did process the message
return TRUE;
}
// +----------------------------------------------------------------------------
// | -WinMain()-
// | Program entry point. Normally you'd find a message loop in WinMain(), but
// | for a dialog-based application, all we have to do is create the dialog and
// | then quit. You should probably add some kind of error-checking facility in
// | case the call to DialogBox() fails. You might also wish to do something
// | with the return value of DialogBox() if it's important. Finally, you could
// | use DialogBoxParam() instead of DialogBox() if you wanted to pass a
// | parameter to the dialog box.
// +----------------------------------------------------------------------------
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
DialogBox(hInstance, // handle to the application
MAKEINTRESOURCE(IDD_MAINDIALOG), // name of the dialog resource to use
NULL, // handle to the dialog's parent window
DialogProc); // name of the callback function
return 0;
}
The code should be fairly self-explanatory, with all those comments in there. The resource.h file is a header that defines the symbol IDD_MAINDIALOG, and you'll also need a resource script that defines the dialog itself. I've attached a sample project. If you have any questions about anything in it, don't hesitate to ask.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
All I am after is a very simple sample Win32 project based on a dialog application.
Can anyone send me a link, its been years since I have had to do this!!
Cheers in advance,
P.
here is a win32 example application.just check it out may be this will help you.i am showing my dialog on Menu click ShowDialog
and here is code for you.
MyApp.h
MyApp.cpp
MyFrame.h
MyFrame.cpp
MyDialog.h
MyDialog.cpp
#include "afxwin.h"
#include "resource.h"
class myDialog: public CDialog
{
private :
int id;
public:
myDialog(int n): CDialog( n)
{
id =n;
}
int OnInitDialog();
};
That's the way to go if you're using MFC, but since this is a non-MFC forum, here's the strictly WinAPI approach:
Not to be argumentive but what are some of the reasons for not wanting to use an existing windowing framework like MFC, ATL, or WTL? I'm not being critical, I'm justing trying to see things from the other point of view.
Not to be argumentive but what are some of the reasons for not wanting to use an existing windowing framework like MFC, ATL, or WTL? I'm not being critical, I'm justing trying to see things from the other point of view.
Arjay
I honestly couldn't tell you. The only reason I posted pure WinAPI code is that that's what this forum is supposed to be for. While I do think that learning something about WinAPI is a decent idea (because it helps one understand how frameworks like MFC function and thus how to use them correctly and efficiently), said frameworks are very convenient and can simplify development in many ways. If I were writing a dialog-based application myself, I'd use MFC.
Not to be argumentive but what are some of the reasons for not wanting to use an existing windowing framework like MFC, ATL, or WTL? I'm not being critical, I'm justing trying to see things from the other point of view.
Arjay
a greater sense of control. knowledge. using MFC requires at least a bit of c++ understanding also so someone who has programmed in C forever would probably find the direct Win32 approach more familiar.
a greater sense of control. knowledge. using MFC requires at least a bit of c++ understanding also so someone who has programmed in C forever would probably find the direct Win32 approach more familiar.
Smasher/Devourer
About your comment about dialogs:
// +----------------------------------------------------------------------------
// | -WinMain()-
// | Program entry point. Normally you'd find a message loop in WinMain(), but
// | for a dialog-based application, all we have to do is create the dialog and
// | then quit. You should probably add some kind of error-checking facility in
// | case the call to DialogBox() fails. You might also wish to do something
// | with the return value of DialogBox() if it's important. Finally, you could
// | use DialogBoxParam() instead of DialogBox() if you wanted to pass a
// | parameter to the dialog box.
// +----------------------------------------------------------------------------
You have missed modeless dialogs.
Above does not apply to a modeless dialogs that may be used for example as a child of the frame window in or even as main window of the application.
In this case main message loop is necessary as well as IsDialogMessage call from a loop to.
There are only 10 types of people in the world: Those who understand binary and those who do not.
Smasher/Devourer
You have missed modeless dialogs.
Above does not apply to a modeless dialogs that may be used for example as a child of the frame window in or even as main window of the application.
In this case main message loop is necessary as well as IsDialogMessage call from a loop to.
I wrote that code to be a WinAPI analogue of what you get when you create a dialog-based application with the MFC AppWizard. In other words, the box created from IDD_MAINDIALOG is assumed to be the application's main window. Under that specific set of circumstances, where the dialog's parent window is always set to NULL, does it matter whether the dialog is modal or modeless?
My Windows programming experience is admittedly quite limited, so it could be that I'm missing something obvious here. But I'm not sure why you'd want to create a modeless dialog in this situation.
I wrote that code to be a WinAPI analogue of what you get when you create a dialog-based application with the MFC AppWizard. In other words, the box created from IDD_MAINDIALOG is assumed to be the application's main window. Under that specific set of circumstances, where the dialog's parent window is always set to NULL, does it matter whether the dialog is modal or modeless?
Yes, in API based application it maters. In MFC application CWinApp provides proper handling of MFC modeless dialog, while message loop in Win32 application generated by app wizard does not.
Anyway, MFC dialogs ara always created as modeless. Modal state is achieved by disabling application main window and establishing dialog’s local message loop.
Originally Posted by Smasher/Devourer
My Windows programming experience is admittedly quite limited, so it could be that I'm missing something obvious here.
Underestimating yourself? I think your posts are pretty good.
Originally Posted by Smasher/Devourer
But I'm not sure why you'd want to create a modeless dialog in this situation.
Originally Posted by beecheyp
sample Win32 project based on a dialog application.
If it were "Win32 application project based on a dialog", it would have been clearer. I just thought that modeless dialog as main window, or modeless dialog in SDI or MDI –like QIN32 application falls into above requirement.
Your point is well taken; I thought that mentioning modeless dialog would supplement your post.
There are only 10 types of people in the world: Those who understand binary and those who do not.
I was just wondering why one would want a dialog-based application rather than a regular windowed application? Is there a major advantage I'm missing? I've always used regular windows.
I was just wondering why one would want a dialog-based application rather than a regular windowed application? Is there a major advantage I'm missing? I've always used regular windows.
It really all depends on what you are doing. If you are manipulating a relatively small amount of data that can be shown with a few controls, then a dialog maybe the way to go. On the other hand, if you have more dynamic data (and lots of it), a windowed app might be better. Another way to look at this, is to determine how long the application will remain open. Usually dialog apps are for short term use, like changing system sound settings for example. Conversely, a windowed app usually is for longer use, such as Explorer.exe viewing files.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.