|
Take Control of Print Preview
Use the PrintPreviewControl component to enhance your app's printing features.
by Tim Patrick
Posted May 10, 2004
Technology Toolbox: VB.NET, .NET Framework
The .NET Framework brings many new features that make complex or cumbersome programming tasks a breeze. Take printing for example. While Visual Basic 6.0 had easy-to-use features for creating printer output, you had to build the print preview features yourself if you wanted your user to preview the output. The Visual Studio .NET Windows Forms system includes not only one, but two methods to present a preview of the printer output to your user: the PrintPreviewDialog component and the PrintPreviewControl component. They both have the advantage of being able to use a single class (PrintDocument) to handle printing to both the preview device and the actual printer.
The PrintPreviewDialog control packages a ready-to-use form that displays your printer output. But why should you use that when you can leverage the power of the PrintPreviewControl control instead? In this article, I'll cover PrintPreviewDialog's features, then show you how to implement a print preview dialog that uses PrintPreviewControl to add a few features that aren't in the default PrintPreviewDialog component.
PrintPreviewDialog includes all of the most basic features you generally require when previewing printed output. It displays each page graphically, allows you to zoom in or out, enables you to jump to a specific page by number, and permits you to view multiple pages at once. Yet it also has some liabilities. As a "black box," there's little you can do to enhance its features. Sure, you could derive a new class from it, but because its constituent controls are inside "the box," there is only so much you can (or should) do in the derived instance. (The PrintPreviewControl component is also a black box, but the fact that it is a control opens up a much larger range of possibilities.)
There is another issue with PrintPreviewDialog. The PrintDocument class that you use to draw your per-page output doesn't know whether it's sending its output to the screen or to a print device. This is by design, and generally is a great thing. However, there might be times when you want to generate different output for print preview and final print. I needed to print some mailing labels recently. During print preview, I opted to draw the boundaries of each label using a light color to give the user a sense of where the text would appear in each physical label. On my print form, I had separate Print and Print Preview selections, and I set a previewMode Boolean flag as needed. It worked until the user clicked on the Print button in Print Preview. Now, PrintDocument was going to the actual printer, but my previewMode flag was still set to True. PrintPreviewDialog does not expose an event for the Print button. Oh despair. There are tricks you can use to hook into the event stream and catch the message for the Print button, but they might not work in future releases of the .NET Framework.
So, in general, the PrintPreviewDialog component is useful, but it goes against one of the main themes of software development: Give the programmer the maximum features possible so that he or she can provide the right features to the end user. You, as a programmer, require sufficient features from your software language and tools so that you can provide the best, the most precise, and the most controlled experience for users.
Back to top
|