Print Preview Multiple Paints

I am having problems with my standard Document/View application with Print
Preview.

If I choose only to have one page displayed, it works fine.  If I choose 2
pages to be displayed side by side, my OnPrint() function gets called over
and over as follows:

OnPrint (pInfo->m_nCurPage = = 1)
OnPrint (pInfo->m_nCurPage = = 2)
OnPrint (pInfo->m_nCurPage = = 1)
OnPrint (pInfo->m_nCurPage = = 2)
OnPrint (pInfo->m_nCurPage = = 1)
OnPrint (pInfo->m_nCurPage = = 2)

Again and again, up to 11 times.  My printing code isn't (yet) the fastest
on the planet so this takes agessssss.

I also note that whilst printing page 1, the status bar includes the caption
"Page 1" and whilst printing page 2 the status bar caption says "Pages 1-2".

Has anyone seen this before or can suggest why it might be happening?

Keith


0
2/18/2004 1:58:06 PM
vc.mfc 33608 articles. 0 followers. Follow

5 Replies
508 Views

Similar Articles

[PageSpeed] 13

Keith,

Mulit-page printing is notoriously tricky. In this case, let me quote
directly from MSDN,

"Another example is the case in which the length of the document is not
known until it is printed. In this situation, the view class tests for the
end of the document each time a page is printed. When the end is reached,
the view class sets the m_bContinuePrinting member of CPrintInfo to FALSE;
this informs the framework to stop the print loop."

So, an informed guess is that bContinuePrinting is not being set to FALSE in
your app. Where is this supposed to happen? Another quote:

"The framework relies on your view class�s OnPrepareDC function to tell it
when to stop. After each call to OnPrepareDC, the framework checks a member
of the CPrintInfo structure called m_bContinuePrinting. Its default value is
TRUE. As long as it remains so, the framework continues the print loop. If
it is set to FALSE, the framework stops. To perform print-time pagination,
override OnPrepareDC to check whether the end of the document has been
reached, and set m_bContinuePrinting to FALSE when it has. "

So, perhaps you've overridden OnPrepareDC, and the CPrintInfo
m_bContinuePrinting is not being set properly?

Johan Rosengren
Abstrakt Mekanik AB

"Keith Sheppard" <keith.sheppard@tesco.net> a �crit dans le message de
news:%233IPxdi9DHA.2736@TK2MSFTNGP10.phx.gbl...
> I am having problems with my standard Document/View application with Print
> Preview.
>
> If I choose only to have one page displayed, it works fine.  If I choose 2
> pages to be displayed side by side, my OnPrint() function gets called over
> and over as follows:
>
> OnPrint (pInfo->m_nCurPage = = 1)
> OnPrint (pInfo->m_nCurPage = = 2)
> OnPrint (pInfo->m_nCurPage = = 1)
> OnPrint (pInfo->m_nCurPage = = 2)
> OnPrint (pInfo->m_nCurPage = = 1)
> OnPrint (pInfo->m_nCurPage = = 2)
>
> Again and again, up to 11 times.  My printing code isn't (yet) the fastest
> on the planet so this takes agessssss.
>
> I also note that whilst printing page 1, the status bar includes the
caption
> "Page 1" and whilst printing page 2 the status bar caption says "Pages
1-2".
>
> Has anyone seen this before or can suggest why it might be happening?
>
> Keith
>
>


0
2/20/2004 7:37:25 AM
Keith,

"Keith Sheppard" <keith.sheppard@tesco.net> a �crit dans le message de
news:uqMrhMf%23DHA.2404@TK2MSFTNGP12.phx.gbl...
> Johan
>
> Thanks for the suggestions.
>
> >>Another example is the case in which the length of the document is not
> known until it is printed.
>
> Actually I do know the length of the document.  In my OnPreparePrinting
> override I call:
>
>     pInfo->SetMinPage(1);
>     pInfo->SetMaxPage(m_PrintSizeInPages.cx * m_PrintSizeInPages.cy);
>
> In the test case, the document is 3x4 = 12 pages.  I therefore don't ever
> set m_bContinuePrinting FALSE because not only is the print size known, I
am
> not anywhere near end of document when previewing the first two pages.
> Despite all this, my OnDraw code gets called 11 times for the first pair
of
> pages.  Note that this only happens for the first pages.  If I move on to
> pages 2/3, each gets painted only once.
>

Ouch, this sounds like a prime candidate for some single-stepping. Would it
perhaps be possible for you to mail me a project exhibiting this behaviour,
preferably one not taking a week to set up :-)))? My return-address is
valid.

Johan Rosengren
Abstrakt Mekanik AB

> Keith
>
>
>
>
>


0
2/21/2004 1:20:52 PM
Keith,

"Keith Sheppard" <keith.sheppard@tesco.net> a �crit dans le message de
news:%23RcCyoi%23DHA.888@tk2msftngp13.phx.gbl...
> Johan
>
> Thanks for your kind offer but I have found and fixed my bug.  It was a
> little obscure, hence the amount of time taken to find it.
>

Indeed it was :-) And me single-stepping the printing code would not have
been of much help! But anyway, great you're on the track again.

Johan Rosengren
Abstrakt Mekanik AB

<snip>


0
2/21/2004 7:46:32 PM
Johan

Thanks for the suggestions.

>>Another example is the case in which the length of the document is not
known until it is printed.

Actually I do know the length of the document.  In my OnPreparePrinting
override I call:

    pInfo->SetMinPage(1);
    pInfo->SetMaxPage(m_PrintSizeInPages.cx * m_PrintSizeInPages.cy);

In the test case, the document is 3x4 = 12 pages.  I therefore don't ever
set m_bContinuePrinting FALSE because not only is the print size known, I am
not anywhere near end of document when previewing the first two pages.
Despite all this, my OnDraw code gets called 11 times for the first pair of
pages.  Note that this only happens for the first pages.  If I move on to
pages 2/3, each gets painted only once.

Keith





0
2/23/2004 9:53:44 AM
Johan

Thanks for your kind offer but I have found and fixed my bug.  It was a
little obscure, hence the amount of time taken to find it.

My application's view windows include the feature that, in some drawing
modes, if the mouse pointer is near the edge of the client area, the view
automatically scrolls.  I implemented this in my OnIdle() code.  Within
OnIdle(), for each open document I was enumerating all open views and
offering each view the chance to auto-scroll.

What I did not realise was that when you do Print Preview, the framework
creates a new view on the document.  This view is of a class specifically
designed to handle print preview.  My OnIdle code was assuming, incorrectly,
that all open views would be of my own view handler class.  I was therefore
taking the return value from GetNextView() and calling one of my view
handler's methods on it without checking the actual class of the object
returned by GetNextView().  Of course, the print preview handler class
doesn't have any of my view class's private data.  As a result, the method
call was deciding that the print preview needed to be auto scrolled :(

A quick DYNAMIC_DOWNCAST() has fixed the problem.

Keith




0
2/23/2004 4:27:53 PM
Reply:

Similar Artilces: