Board index » cppbuilder » Dialogs and templates

2007-06-14 09:27:36 PM
cppbuilder47
Has any one used a template with a dialog?
~ JD
 

JD wrote:
That's the usual way to do a dialog.
Or are you thinking of CreateDialogIndirect() and the help topic
"Templates in Memory" and creating the template from user input?
 

Bob Gonder < XXXX@XXXXX.COM >wrote:
resourse was one option. Under "Customizing the Page Setup
Dialog Box", I located dlgs.h which defines constants for the
templates and PrnSetup.dlg which has some actual templates.
looks very interesting.
My objective is to combine 2 dialogs - PageSetupDlg and a
TPrintDialog. I can live with them being seperate but
there's a bug with TPrintDialog where the Collate property
always returns false. It may very well be that none of my
printers support Collate and that's why it's always false but
I can still print in a collated fashion and want to use that
feature.
I haven't built the template yet (I feel confident that
that won't be a problem) but what to do after I get it
displayed?
The PAGESETUPDLG struct used with PageSetupDlg() has a
lpfnPageSetupHook so that I can recieve notifications
but I can't find anything on what messages to expect
except for WM_INITDIALOG and help.
Then what do I do when it closes or do I need to keep track of
the fields as they change?
~ JD
 

{smallsort}

JD wrote:
control and "remember" it for yourself. That wouldn't take anything
fancy.
lpPageSetupTemplateName
would indicate that you could just use an RC dialog to drive it.
You would want to use the predefined IDs for the standard items and
unique IDs for your specialized controls.
The one you use most would be
case WM_COMMAND:
switch (wParam)
{
case IDOFYOURCONTROL:
/* your control did something */
You can just process your stuff, and allow the default handler to do
the rest, or you can add more code and override all the buttons.
You get the WM_COMMAND first, so if you return "processed" (true), the
original dialog ignores the message.
You can also add controls or manipulate the dialog on startup in the
WM_INITDIALOG message as the standard dialog has already been created.
The other is to intercept WM_CLOSE or the Ok button and query all the
controls.
Or WM_COMMAND( IDOK )
From one of my dialogs:
case CM_U_OK:
COPY = IsDlgButtonChecked( hDlg, CM_U_COPY );
Subdir = IsDlgButtonChecked( hDlg, CM_U_SUBDIR );
DONOTHING = IsDlgButtonChecked( hDlg, CM_U_DONOTHING);
OVERWRITE = IsDlgButtonChecked( hDlg, CM_U_OVERWRITE);
EndDialog( hDlg, TRUE );
return TRUE;
But you don't want to call EndDialog from a hooked common dialog.
Oh, and the Help nicely mentions:
"The members of the PAGESETUPDLG structure pointed to by the lppsd
parameter indicate the user's selections."
But that would be for the usual suspects, not something new.