Hi,
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.
Printable View
Hi,
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.
take a look here Dialogs you have enough dialogs.
basically:
open MSDEV->New Project->MFC(AppWizard.exe)->Dialog Based (radio button)->Finish.
and you will have your dialog based project.
if i helped dont forget to rate :-)
Cheers
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:
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.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;
}
This thread may help:
http://www.codeguru.com/forum/showthread.php?t=306103
here is a win32 example application.just check it out may be this will help you.i am showing my dialog on Menu click ShowDialogQuote:
Originally Posted by beecheyp
and here is code for you.
MyApp.h
MyApp.cpp
MyFrame.h
MyFrame.cpp
MyDialog.h
MyDialog.cpp
decla:
MyApp.h
MyApp.cppCode:#include <afxwin.h>
class MyApp:public CWinApp
{
public:
BOOL InitInstance();
};
MyApp a;
MyFrame.hCode:#include "MyApp.h"
#include "MyFrame.h"
BOOL MyApp::InitInstance()
{
MyFrame *pMyFrame = new MyFrame;
m_pMainWnd = pMyFrame;
pMyFrame->ShowWindow(3);
return 1;
};
MyFrame.cppCode:#include <afxwin.h>
class MyFrame:public CFrameWnd
{
public:
MyFrame();
int File(int n);
DECLARE_MESSAGE_MAP()
};
MyDialog.hCode:#include "MyFrame.h"
#include "resource.h"
#include "MyDialog.h"
MyFrame::MyFrame()
{
Create(0,"Hello",WS_VISIBLE|WS_OVERLAPPEDWINDOW,rectDefault,this,MAKEINTRESOURCE(IDR_MENU1));
}
int MyFrame::File(int n)
{
switch(n)
{
case 101:
myDialog d(IDD_DIALOG1);
d.DoModal();
break;
}
return 1;
}
BEGIN_MESSAGE_MAP(MyFrame,CFrameWnd)
ON_COMMAND_RANGE(101,102,File)
END_MESSAGE_MAP()
MyDialog.cppCode:#include "afxwin.h"
#include "resource.h"
class myDialog: public CDialog
{
private :
int id;
public:
myDialog(int n): CDialog( n)
{
id =n;
}
int OnInitDialog();
};
Code:#include "MyDialog.h"
myDialog::OnInitDialog()
{
CDialog::OnInitDialog();
if(id==IDD_DIALOG1)
CenterWindow(GetDesktopWindow());
else
CenterWindow();
return TRUE;
};
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.Quote:
Originally Posted by Smasher/Devourer
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. ;)Quote:
Originally Posted by Arjay
Quote:
Originally Posted by 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.
Okay, that seems reasonable. Thanks.Quote:
Originally Posted by filthy_mcnasty
Arjay
Smasher/Devourer
About your comment about dialogs:
You have missed modeless dialogs.Quote:
// +----------------------------------------------------------------------------
// | -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.
// +----------------------------------------------------------------------------
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?Quote:
Originally Posted by JohnCz
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.
Hi Smasher/Devourer'
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.Quote:
Originally Posted by Smasher/Devourer
Anyway, MFC dialogs ara always created as modeless. Modal state is achieved by disabling application main window and establishing dialog’s local message loop.
Underestimating yourself? I think your posts are pretty good.Quote:
Originally Posted by Smasher/Devourer
Quote:
Originally Posted by Smasher/Devourer
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.Quote:
Originally Posted by beecheyp
Your point is well taken; I thought that mentioning modeless dialog would supplement your post.
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.Quote:
Originally Posted by richard-aggragant
Arjay
[ Moved Thread ]
This message is about MFC dialog applications and thus it does not fit into WinAPI.