Re: Printing in .NET redundant?

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: David Eu (anonymous_at_discussions.microsoft.com)
Date: 05/12/04 

Date: Tue, 11 May 2004 22:06:04 -0700

> The control *paints* onto a graphics buffer. The *painting* includes overdraw
> and other features including alpha
> blending, and many other feature rich items.

I can appreciate the ability to have those features such as alpha blending or
adding custom graphics. It is great to have those things but what about the
basic task of printing a Windows Form?

> You don't need to reverse engineer OnPaint per say. Most of the control drawing
> routines can be found
> in the ControlPaint class so you can handle painting them there. The underlying
> issue is that you generally

The ControlPaint class only allows you to draw geometric primitives. If you want to
print a TabControl that contains several TabPages, each TabPage containing nested
controls such as TextBoxes, RichTextBoxes, DataGrids, etc.. how do you do that
with ControlPaint? You have to code everything yourself.
And how do you print a MonthCalendar?
I have managed to get the printing working for TextBoxes, RadioButtons, Buttons, RichTextBoxes,
Labels, CheckBoxes, etc. but what an arduous task! You have to code for all of the different
appearance attributes - example: text alignment, background images, image alignment, etc...
So yes, you have to reverse engineer OnPaint. You have to attempt to draw
the form exactly as OnPaint draws it.

> If you want to BitBlt it from the screen you are more than welcome. You can
> BitBlt from the screen area to your

That is not a practical solution. Just think of the case where the user has moved
the form so that part of it does not lie within the visible screen space. The rendered
form will be incomplete.

On the subject of BitBlt - you can load an image into a graphics context but you cannot
save a graphics context to an image. Technically this should be a trivial matter.
I suspect that the reason why you cannot save is due rather to a business motive.
Imagine if Microsoft would provide this simple function - it would then be trivial.
All you would have to do is do a form refresh and save the graphics context to an image
buffer and then print the image buffer. You could even preprocess the image buffer,
e.g. cropping, rotating, 2D effects, etc...

> Take the single case of a Listbox with 30 items with only 3 visible. How do you
> print that?
My point ***exactly***. When OnPaint() draws the ListBox does it not draw it correctly with
only the 3 visible items shown? So instead of be given the API hook to tell the ListBox
to draw itself correctly onto the graphics context, we have to write code to
mimic the behaviour of OnPaint.

Quantcast