🚀 go-pugleaf

JD wrote:

>Has any one used a template with a dialog?

You mean a resource file?
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 <notbg@notmindspring.invalid> wrote:
>JD wrote:
>
>>Has any one used a template with a dialog?
>
>You mean a resource file?
>That's the usual way to do a dialog.

From what little info I could find, I had concluded that a
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.

> Or are you thinking of CreateDialogIndirect()

I was specifically looking at PageSetupDlg()

> and the help topic "Templates in Memory"

but it too allows for the template to be in memory so that
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

JD wrote:

>there's a bug with TPrintDialog where the Collate property
>always returns false

Ok, for this you might intercept the WM_COMMAND for the Collate
control and "remember" it for yourself. That wouldn't take anything
fancy.

>I haven't built the template yet (I feel confident that
>that won't be a problem)

This
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 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.

The normal suspects in a window or dialog proc
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.

>Then what do I do when it closes or do I need to keep track of
>the fields as they change?

That's one option.
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.