Frustrating print / printpreview problem

[mike gaskey]

To start, I've been chasing this problem for days and have hit a wall so I've landed here begging for some insight.

Here's the situation:
I have a multi-document app, 6 different document types and each are viewable through a tabbed interface. Of these 6 different document types, one does not have the problem that I am about to describe. There difference between that one document and the others is that it is a single page document while the other are multi-page.

The problem:
When I print a document (even when I print just 1 page as selected via the print dialog) then follow that with a second print request (1 page for example) the page prints with huge fonts. Eye balling the output it would appear to be a 24 point font at least. The problem persists on subsequent print request, until I do a print-preview. Once I do a printpreview, which will work just fine, then follow that by another print request the printed output will be perfect: whatever is crewed up is corrected by the interveening print preview request.

This is driving me crazy: I cannot see any substantial difference between between the document that behaves correctly and the documents with the problem. I have gone line by line comparing the different sets of print logic and again, there is no substantial difference between the one with the correct behavior and the ones wth the problem.

I'm not looking for a solution, just a place to start as I have exhausted every possibility I could imagine.

For reference, I'm using Visual Studio 2005. The view window for all employs CScrollView / QZoomView (enables a zoom capability for views). I had initially thought QZoomView was the cause of the problem but none of the print activities are handled in QZoomView.

Any and all suggestions appreciated.

[Woody]

If the second print request uses unexpected fonts, there must be
somewhere the font size is changed.

You normally set the font in OnBeginPrinting, by selecting the font
you want (which includes a point size) into the DC. If you haven't
chosen a font there, you may be using some default left over from
Print Preview. Otherwise, you can insert checks at various points in
the code, to see what font is currently selected, and isolate where
the font has been changed.

[rajesh anjeara]

Hi all,


I have a doubt about WndowRect of a dialog in OnInitdialog
function, means i do get the x and y (0,0) in Oninitdialog function.
Although the dialog will not be shown before Oninitdialog() function
or during Oninit being executed, i get correct width and height of a
dialog. why does this happen so? can any one help me to understand
this ?

[ScottMcP [MVP]]

Post by rajesh anjeara
Hi all,
   I have a doubt about WndowRect of a dialog in OnInitdialog
function, means i do get the x and y (0,0) in Oninitdialog function.
Although the dialog will not be shown before Oninitdialog() function
or during Oninit being executed, i get correct width and height of a
dialog. why does this happen so? can any one help me to understand
this ?

Rajesh: You should have started a new question, not replied to an
existing question.

During OnInitDialog the dialog window does exist. But it is
invisible.

Invisible things can have a size, even when you can't see them.

[rajesh anjeara]

Post by mike gaskey
To start, I've been chasing this problem for days and have hit a wall so I've landed here begging for some insight.
I have a multi-document app, 6 different document types and each are viewable through a tabbed interface.  Of these 6 different document types, one does not have the problem that I am about to describe. There difference between that one document and the others is that it is a single page document while the other are multi-page.
When I print a document (even when I print just 1 page as selected via the print dialog) then follow that with a second print request (1 page for example) the page prints with huge fonts.  Eye balling the output it would appear to be a 24 point font at least.  The problem persists on subsequent print request, until I do a print-preview.  Once I do a printpreview, which will work just fine, then follow that by another print request the printed output will be perfect: whatever is crewed up is corrected by the interveening print preview request.
This is driving me crazy: I cannot see any substantial difference between between the document that behaves correctly and the documents with the problem.  I have gone line by line comparing the different sets of print logic and again, there is no substantial difference between the one with the correct behavior and the ones wth the problem.
I'm not looking for a solution, just a place to start as I have exhausted every possibility I could imagine.
For reference, I'm using Visual Studio 2005.  The view window for all employs CScrollView / QZoomView (enables a zoom capability for views).  I had initially thought QZoomView was the cause of the problem but none of the print activities are handled in QZoomView.
Any and all suggestions appreciated.