PrintPreviewControl - Hide "Generating Previews" Dialog

[deciacco]

I'm trying to write a label printing SDI app with a small preview on the main form itself. Every time I run the InvalidatePreview event on the preview
control to redraw the preview I get the "Generating Previews" dialog box while the preview is being generated. I want to suppress this. I've been able
to find this from another forum:

"The 'Generating Previews' dialog is shown while calculating the layout for pages in OnPaint(). One of our devs suggested the only way to avoid this
dialog is to override the OnPaint, do your own layout- passing your own PrintController and not calling the base."

I tried to create a custom control and override onpaint, but I could not get it to work.

I have been able to hide the dialog if I print directly to the printer by using the StandardPrintController, but this does not work with the preview.

Has anybody found another solution to this, or have other suggestions?

Thanks.

 

[Peter Duniho]

[...]
I tried to create a custom control and override onpaint, but I could not
get it to work.

What didn't work? What *did* work?

I have been able to hide the dialog if I print directly to the printer
by using the StandardPrintController, but this does not work with the
preview.

What dialog did you hide? I would not expect to see the "Generating
Previews" dialog when printing to an actual printer, nor have I in the few
times I've done any printing with the .NET classes. Did you hide some
other dialog instead? If so, in what way would that success be relevant
to this question?

Has anybody found another solution to this, or have other suggestions?

In the overridden OnPaint() method, do you call the base method? If so, I
would guess that's part of your problem. The point to overriding would be
to avoid using the built-in functionality. You can only do that by
implementing the *entire* preview drawing functionality and not calling
the base method (as the quote you offered suggests).

Frankly, this seems like a lot of work for a questionable goal. It's not
clear to me why it's so bad to provide the user with some feedback
regarding what is going on. In fact, usually it's the opposite that users
complain about: some application is busy doing something, but there's no
feedback to the user that that's happening, what the application is doing,
or how long it will take.

At the very least, you may want to consider elaborating on your question.
As it stands now, what information we have regarding your question is
pretty vague. It's hard to offer specific, useful advice when the problem
description isn't very clear.

Pete

 

[deciacco]

Here is a link to an app that is currently written in foxpro 9. I want to build
the exact same application in c# 2.

http://deciacco.com/blog/wp-content/uploads/2006/12/lblprint1.gif

The user is able to search for a record and when they click on the record in the
data grid a quick label preview is generated.

In C#, I figured the best way to do this, is to use the printpreviewcontrol on the sdi form.

I started experimenting with the control on a form and I got it to do a basic print preview,
the problem was that every time the preview got generated I got the dialog box.

Normally, it would be good to give the user some feedback, but I think in an application like
this, the preview is generated so quickly that the busy cursor is more than sufficient, instead
of having a dialog pop up every time a user selects a different record or uses one of the radio
buttons to add more information to the label.

If I were to print the document, there is a status dialog that pops up that is very similar to
the "Generating Preview" dialog, and this dialog can be suppressed by setting the printcontroller
of the printdocument to a standardprintcontroller.

When I tried to create my own custom printpreviewcontrol I started out to override the OnPaint method.
I used Reflector to get the code in the OnPaint method of the .net 2 printpreviewcontrol, because I have
no idea how to implement it, but I was able to determine what not to include so that the
"Generating Preview" dialog would not show.

What I discovered is that the printpreviewcontrol has a private method ComputePreview where it uses a
printcontrollerwithstatusdialog as the printcontroller. I believe this is what is causing the "Gen Prev"
dialog that I want to suppress. The problem is that this method is private and therefor cannot be overwritten.
So, not only do you have to override the onpaint, you also have to create your own version of this method
that calls the standardprintcontroller.

I was going to attempt this, but as I started to implement the OnPaint of my custom control and copied over
the code, there were a few lines of code that gave me problems.

format.Alignment = ControlPaint.TranslateAlignment(ContentAlignment.MiddleCenter);
format.LineAlignment = ControlPaint.TranslateLineAlignment(ContentAlignment.MiddleCenter);

The error I got with these two lines is that the ControlPaint class did not have a TranslateAlignmet method,
nor did it have a TranslateLineAlignment method.

Another line of code that did not work for me was this one:

pevent.Graphics.DrawString(SR.GetString("PrintPreviewExceptionPrinting"), this.Font, brush2, base.ClientRectangle, format);

The error here was with SR. I could not get access to it because of it's protection level.

When I got these two errors I gave up.

Thanks!

This is where I got Reflector from:
http://www.aisto.com/roeder/dotnet/

[...]
I tried to create a custom control and override onpaint, but I could
not get it to work.

What didn't work? What *did* work?

I have been able to hide the dialog if I print directly to the printer
by using the StandardPrintController, but this does not work with the
preview.

What dialog did you hide? I would not expect to see the "Generating
Previews" dialog when printing to an actual printer, nor have I in the
few times I've done any printing with the .NET classes. Did you hide
some other dialog instead? If so, in what way would that success be
relevant to this question?

Has anybody found another solution to this, or have other suggestions?

In the overridden OnPaint() method, do you call the base method? If so,
I would guess that's part of your problem. The point to overriding
would be to avoid using the built-in functionality. You can only do
that by implementing the *entire* preview drawing functionality and not
calling the base method (as the quote you offered suggests).

Frankly, this seems like a lot of work for a questionable goal. It's
not clear to me why it's so bad to provide the user with some feedback
regarding what is going on. In fact, usually it's the opposite that
users complain about: some application is busy doing something, but
there's no feedback to the user that that's happening, what the
application is doing, or how long it will take.

At the very least, you may want to consider elaborating on your
question. As it stands now, what information we have regarding your
question is pretty vague. It's hard to offer specific, useful advice
when the problem description isn't very clear.

Pete

 

[Peter Duniho]

[...]
Normally, it would be good to give the user some feedback, but I think
in an application like
this, the preview is generated so quickly that the busy cursor is more
than sufficient, instead
of having a dialog pop up every time a user selects a different record
or uses one of the radio
buttons to add more information to the label.

I do agree that it would be better without the status dialog in this
case. On the other hand, you seem to be going to an awful lot of trouble
in order to work around something that, while not perfect, doesn't seem to
me to be a really big problem.

That said, you've selected what *I* think may be a particular difficult
route to reimplementing the OnPaint() method. It seems to me that the key
behavior of the OnPaint() method is to set up a Graphics instance that
looks like a printer page and then pass that off to the PrintPage event
handler. This would involve creating a Bitmap or Metafile into which the
client can draw (Bitmap is probably just fine, but Metafile would allow
for easy reuse of the drawn image at different sizes, if that's something
you think could be useful), setting up the margins, clipping, etc.

I admit, I haven't looked closely enough at the .NET printing API to know
for sure where all of this gets implemented. There seems to be a
PrintController class you need to create, and then perhaps a custom
control to take advantage of that. The basic idea of a print preview is
not hard, so the idea that you should have to dive into the .NET
implementation of a particular class, trying to copy all of its internals
when probably much of what's in there isn't even applicable to the common
case, that doesn't seem right to me.

If you *are* going to try to suppress this dialog, I would think that
coming at it from the other direction, by simply reinventing the basic
functionality you need for print preview, would be more efficient.
There's likely just too much clutter in the existing implementation for it
to be a practical template to use (not that the clutter doesn't have its
use...just that it probably exists to handle a broader variety of
situations than you will need to handle).

Pete