🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: borland.public.cppbuilder.nativeapi
13 messages
13 total messages Started by JD Tue, 19 Jun 2007 22:23
Dialog child window
#1793
Author: JD
Date: Tue, 19 Jun 2007 22:23
15 lines
1523 bytes
Looking at TPrintDialog specifically, there exists a CheckBox
with the caption (WindowText) of "C&ollate". However, it's
class name is "Button".

I can subclass it's Window Proc and catch WM_ mouse messages
just fine but there's problem in that the dialog remembers
what the user had it set to when it closed so that if reopened,
the CheckBox is set accordingly but the dialog's Collate getter
and setter methods fail to do anything if the printer does not
support collating.

So .... Can I query the control to find out if it's checked
and dynamically check or uncheck it?

~ JD
Re: Dialog child window
#1794
Author: Remy Lebeau (TeamB)
Date: Tue, 19 Jun 2007 22:43
39 lines
2480 bytes
"JD" <nospam@nospam.com> wrote in message
news:46785769@newsgroups.borland.com...

> Looking at TPrintDialog specifically, there exists a
> CheckBox with the caption (WindowText) of "C&ollate".
> However, it's class name is "Button".

Like much of the VCL, TPrintDlg is just a wrapper for Win32 API calls.
In this case, the PrintDlg() function.  So the entire dialog is
controlled by the OS, not the VCL.  "Button" is the Win32 control that
controls push buttons, radio buttons, and checkboxes at the API layer.

> the dialog remembers what the user had it set to when it closed
> so that if reopened, the CheckBox is set accordingly

TPrintDialog has its own Collate property.  It is set to False by
default.  It is set to True if the user checked the box in the dialog.
If you do not reset the property back to False before calling
Execute() again, then the box will be initially checked when the
dialog appears.

> the dialog's Collate getter and setter methods fail to do anything
> if the printer does not support collating.

There is no getter/setter for that checkbox.  It is not a VCL control.
If you read the Win32 API documentation for the PRINTDLG structure,
you will see that the dialog simply reports whether the user checked
the box or not.  If the printer does not actually support collation,
then you have to implement it yourself in your printing code.

> So .... Can I query the control to find out if it's checked
> and dynamically check or uncheck it?

If you have the control's HWND, then you can do whatever you want with
it.  Look at the BM_GETCHECK and BM_SETCHECK messages.


Gambit
Re: Dialog child window
#1795
Author: Bob Gonder
Date: Tue, 19 Jun 2007 23:33
26 lines
1605 bytes
JD wrote:

>Looking at TPrintDialog specifically,

Don't know about TPrintDialog.
Does it just wrap the common dialog?

>So .... Can I query the control to find out if it's checked
>and dynamically check or uncheck it?

The ID for Collate should be  PD_COLLATE

So
case WM_INITDIALOG:
	/* default dialog has already been initialized */
	/* anything you do here overrides the defaults */
	CheckDlgButton( hDlg, PD_COLLATE,
		Collate ? BST_CHECKED : BST_UNCHECKED );

case WM_COMMAND:
    switch (wParam)
    {
	case  PD_COLLATE:
		Collate = (BST_CHECKED ==
			 IsDlgButtonChecked( hDlg, PD_COLLATE));
		return 1;
Re: Dialog child window
#1697
Author: JD
Date: Wed, 20 Jun 2007 08:50
34 lines
2116 bytes
>> the dialog remembers what the user had it set to when it closed
>> so that if reopened, the CheckBox is set accordingly
>
> TPrintDialog has its own Collate property.  It is set to False by
> default.  It is set to True if the user checked the box in the dialog.
> If you do not reset the property back to False before calling
> Execute() again, then the box will be initially checked when the
> dialog appears.

It doesn't work like that. The Collate property is always false - period -
even after checking it and closing the dialog.

>> the dialog's Collate getter and setter methods fail to do anything
>> if the printer does not support collating.
>
> There is no getter/setter for that checkbox.

I presumed that there was because of the way that I observed how it was 
working
just as I presumed it's behavior was due to my printers not supporting 
collating but
I never got around to confirming it.

>> So .... Can I query the control to find out if it's checked
>> and dynamically check or uncheck it?
>
> If you have the control's HWND, then you can do whatever you want with
> it.  Look at the BM_GETCHECK and BM_SETCHECK messages.

That's what I did.

Thanks!

~ JD
Re: Dialog child window
#1698
Author: JD
Date: Wed, 20 Jun 2007 09:04
96 lines
4355 bytes
> Don't know about TPrintDialog.
> Does it just wrap the common dialog?

Yes.

>>So .... Can I query the control to find out if it's checked
>>and dynamically check or uncheck it?
>
> The ID for Collate should be  PD_COLLATE
>
> So
> case WM_INITDIALOG:

I wanted to avoid using the win32 call so I just subclassed the control's 
Window Proc from
the Dialog's OnShow event:

//---------------------------------------------------------------------------
#ifdef STRICT
#define COLLATEWNDPROC WNDPROC
#else
#define COLLATEWNDPROC FARPROC
#endif
//---------------------------------------------------------------------------
    private:
        HWND CollateHandle;
        bool FCollate;
        LONG CollateWndProcPtr;
        COLLATEWNDPROC OldCollateWndProc;
        void __fastcall CollateWndProc( TMessage &Message );
        static bool __stdcall EnumChildCallBack( HWND hWnd, LPARAM lParam );
//---------------------------------------------------------------------------

//---------------------------------------------------------------------------
void __fastcall TPreviewForm::PrintButtonClick(TObject *Sender)
{
    if( PrintDialog1->Execute() )
      {
          // check FCollate
      }
    if( CollateWndProcPtr ) FreeObjectInstance( 
reinterpret_cast<void*>(CollateWndProcPtr) );
}
//---------------------------------------------------------------------------
void __fastcall TPreviewForm::PrintDialog1Show(TObject *Sender)
{
    CollateHandle = NULL;
    CollateWndProcPtr = NULL;
    ::EnumChildWindows( PrintDialog1->Handle, 
(WNDENUMPROC)EnumChildCallBack, (LPARAM)this );
    if( CollateHandle )
      {
          CollateWndProcPtr = reinterpret_cast<LONG>( 
MakeObjectInstance(CollateWndProc) );
          OldCollateWndProc = reinterpret_cast<COLLATEWNDPROC>( 
::SetWindowLong(CollateHandle, GWL_WNDPROC, CollateWndProcPtr) );
      }
}
//---------------------------------------------------------------------------
bool __stdcall TPreviewForm::EnumChildCallBack( HWND hWnd, LPARAM lParam )
{
    char Buffer[256] = { 0 };
    if( ::GetClassName(hWnd, Buffer, 255) )
      {
          if( stricmp(Buffer, "Button") == 0 )
            {
                ::GetWindowText( hWnd, Buffer, 255 );
                if( stricmp(Buffer, "C&ollate") == 0 )
                  {
                      reinterpret_cast<TPreviewForm*>( 
lParam )->CollateHandle = hWnd;
                      return FALSE;
                  }
            }
      }
    return TRUE;
}
//---------------------------------------------------------------------------
void __fastcall TPreviewForm::CollateWndProc( TMessage &Message )
{
    if( Message.Msg == WM_DESTROY )
      {
          if( ::SendMessage(CollateHandle, BM_GETCHECK, NULL, NULL) == 
BST_CHECKED ) FCollate = true;
          else FCollate = false;
          Message.Result = ::CallWindowProc( OldCollateWndProc, 
CollateHandle, Message.Msg, Message.WParam, Message.LParam );
          ::SetWindowLong( CollateHandle, GWL_WNDPROC, 
reinterpret_cast<LONG>(OldCollateWndProc) );
      }
    else Message.Result = ::CallWindowProc( OldCollateWndProc, 
CollateHandle, Message.Msg, Message.WParam, Message.LParam );
}
//---------------------------------------------------------------------------

~ JD
Re: Dialog child window
#1699
Author: Bob Gonder
Date: Wed, 20 Jun 2007 16:18
18 lines
1707 bytes
JD wrote:

>> case WM_INITDIALOG:
>
>I wanted to avoid using the win32 call so I just subclassed the control's 

Why is that?
You are still using plenty of Win32 calls (many more than needed IMO)

>void __fastcall TPreviewForm::PrintDialog1Show(TObject *Sender)
>{
>    CollateHandle = NULL;
>    CollateWndProcPtr = NULL;
>    ::EnumChildWindows( PrintDialog1->Handle, 
>(WNDENUMPROC)EnumChildCallBack, (LPARAM)this );

That is a very long-winded way to say
	CollateHandle = GetDlgItem( PrintDialog1->Handle, PD_COLLATE);
Re: Dialog child window
#1700
Author: Remy Lebeau (TeamB)
Date: Wed, 20 Jun 2007 16:50
45 lines
2359 bytes
"JD" <nospam@nospam.com> wrote in message
news:4678ea55@newsgroups.borland.com...

> It doesn't work like that. The Collate property is always false -
period -
> even after checking it and closing the dialog.

According to the Win32 API documentation:

    PRINTDLG
    Flags

    PD_COLLATE
    Places a checkmark in the Collate check box when set on input.
When the PrintDlg function returns, this flag indicates that the user
selected the Collate option and the printer driver does not support
collation. In this case, the application must provide collation. If
PrintDlg sets the PD_COLLATE flag on return, the dmCollate member of
the DEVMODE structure is undefined.

So in this case, if you check on the Collate checkbox and close the
dialog, the Collate property will be false if your printer actually
supports collation, so you don't have to do anything extra for it.
For example:

    if( PrintDialog1->Execute() )
    {
        if( PrintDialog1->Collate )
        {
            // you have to implementation collation yourself in your
printing code...
        }
        else
        {
            // the printer will handle the collation automatically, or
the
            // user did not choose to use collation. either way, there
is
            // nothing extra for you to do here ...
        }
    }


Gambit
Re: Dialog child window
#1705
Author: JD
Date: Thu, 21 Jun 2007 06:37
16 lines
1547 bytes
"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>> It doesn't work like that. [...]

> According to the Win32 API documentation: [...]
> When the PrintDlg function returns, this flag indicates
> that the user selected the Collate option and the printer
> driver does not support collation.

TPrintDialog does not respect this.

> In this case, the application must provide collation.

One can not if TPrintDialog::Collate is always false.

~ JD
Re: Dialog child window
#1706
Author: JD
Date: Thu, 21 Jun 2007 06:38
19 lines
1457 bytes
Bob Gonder <notbg@notmindspring.invalid> wrote:
>
>>I wanted to avoid using the win32 call so I just subclassed
>> the control's
>
> Why is that? You are still using plenty of Win32 calls

I wanted a VCL solution. The API calls are to get around
a bug and I think that that makes a difference.

> (many more than needed IMO)

Only by one!

>That is a very long-winded way to say

Well ... I had already coded it before I read your post <g>.

~ JD 
Re: Dialog child window
#1707
Author: Remy Lebeau (TeamB)
Date: Thu, 21 Jun 2007 09:38
20 lines
1707 bytes
"JD" <nospam@nospam.com> wrote in message
news:467a1ca2@newsgroups.borland.com...

> TPrintDialog does not respect this.

Yes, it does.

> One can not if TPrintDialog::Collate is always false.

You missed the point I was trying to make.  If the Collate property
returns *false* after Execute() exits, then the printer natively
suppports collation and you *do not* have to do anything yourself in
your code.  But if Collate returns *true*, then the printer *do not*
support collation, and you will have to collate the pages manually.
Obviously, your printer does support collation if the property is
always false.


Gambit
Re: Dialog child window
#1708
Author: Remy Lebeau (TeamB)
Date: Thu, 21 Jun 2007 09:40
12 lines
1277 bytes
"JD" <nospam@nospam.com> wrote in message
news:467a1cdf@newsgroups.borland.com...

> I wanted a VCL solution. The API calls are to get
> around a bug and I think that that makes a difference.

There is no bug here.  You are simply not understanding how to
actually use it properly.


Gambit
Re: Dialog child window
#1709
Author: JD
Date: Thu, 21 Jun 2007 11:54
32 lines
2212 bytes
"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote:
>
>> TPrintDialog does not respect this.
>
>Yes, it does.
>
>> One can not if TPrintDialog::Collate is always false.
>
> You missed the point I was trying to make.

You know ... I read everything that the archives had to offer
on this before asking for help and not one of the posts were
inconsistant with my concept because it was based on what they
concluded, save one. The OP kept insisting that his printer
supported collating and the others gave up on him.

When archived, your post will be the only published 'solution'
for this and I would suggest that your comments on how the
Collate property works should be added to the documentation
because this is what the help says (BCB6):

    Description

    Collate is true whenever the Collate check box is selected
    in the Print dialog. To make the dialog open with the
    check box selected, set Collate to true in the Object
    Inspector or in program code.


Thanks for not giving up on me!

~ JD
Re: Dialog child window
#1717
Author: Remy Lebeau (TeamB)
Date: Thu, 21 Jun 2007 17:27
44 lines
2513 bytes
"JD" <nospam@nospam.com> wrote in message
news:467a66f5@newsgroups.borland.com...

> When archived, your post will be the only published 'solution'
> for this and I would suggest that your comments on how the
> Collate property works should be added to the documentation
> because this is what the help says (BCB6):

That is what the Win32 API documentation is for:

    PRINTDLG
    Flags

    PD_COLLATE
    Places a checkmark in the Collate check box when set on input.
When the PrintDlg function returns, this flag indicates that the user
selected the Collate option and the printer driver does not support
collation. In this case, the application must provide collation. If
PrintDlg() sets the PD_COLLATE flag on return, the dmCollate member of
the DEVMODE structure is undefined.


    DEVMODE

    dmCollate
    Specifies whether collation should be used when printing multiple
copies. (This member is ignored unless the printer driver indicates
support for collation by setting the dmFields member to DM_COLLATE.)
This member can be be one of the following values:

    DMCOLLATE_TRUE
    Collate when printing multiple copies.

    DMCOLLATE_FALSE
    Do not collate when printing multiple copies.

    Using DMCOLLATE_TRUE provides faster, more efficient output for
collation, since the data is sent to the device driver just once, no
matter how many copies are required. The printer is told to simply
print the page again.


Gambit
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads