We’ve made our way through a lot in this chapter, and now it’s time for a quick dessert. We haven’t done anything with printing so far. One of Cocoa’s most powerful programming features is that printing is extremely easy. Mac OS X’s Quartz, which is used to display things on the screen, is also used to send images to the printer. If your program can display itself on the screen, it can print. It’s that simple.
As we’ll see in Chapter 15, when an NSView object receives a drawRect: message, the view responds by drawing itself in the current graphics context. Normally, the current graphics context is the screen, and the drawRect: message results in the view’s drawing itself on the computer’s display. But if the current graphics context is the printer, the drawRect: method causes the view to generate instructions that cause itself to be printed. Under normal circumstances, you never send the drawRect: message directly to a view. This message is sent for you by the AppKit when the view needs to display itself. You can force a view to display itself by sending it a display message.
Printing is very similar. To have a view print itself, you just send the view a print: message. This causes the AppKit to display a Print panel (dialog), ask the user which printer he wishes to use, and then create a printer context. The view is then sent a sequence of drawRect: messages, one for each page. The result of the drawing operations is captured and then sent to the printer. Thus, the only thing that you need do to make an NSView object print its contents is send it the print: message!
You can override other methods in the NSView class to get more control over printing. For example, you can override the printJobTitle method to change the name of your print job. The beginDocument method is invoked when your document starts printing, and endDocument is invoked when the printing is finished. Each page’s printing begins with the beginPageInRect: method’s being invoked.
One of the truisms of object-oriented programming, and especially
programming with Cocoa, is that the easiest line of code that you can
possibly write, the line of code that is the easiest to debug, and
the line of code that is easiest to keep in sync with future versions
of the operating system, is the line of code that you
don’t write. By default, the
File → Print menu command in the multiple-document
framework sends the print: action
message to the first responder (you can check this premade connection
by looking at MainMenu.nib in IB).
Recall that when a message is sent to the first responder object, the message is sent to the following objects in the following order, until a recipient for the message is found:
The key window
The key window’s delegate
The application’s main window
The application’s main window’s delegate
The application’s Application object
The application’s Application object’s delegate
When MathPaper is running, the first object that the AppKit queries with the print: method is the NSTextView in the key MathPaper window. The NSTextView, a subclass of NSView, knows how to respond to the print: message and it prints itself. You don’t need to add printing to your MathPaper application — it’s already there![35]
Run MathPaper from PB or the Finder (no new build is necessary).
Type an equation or two into the MathPaper window.
Choose MathPaper’s File → Print menu command to get the Print panel, as shown in Figure 13-8.
Select a printer and click Print. The contents of the MathPaper window will appear on the printed page.
Alternatively, click the Preview button in the Print panel. MathPaper will then create a PDF file and launch the Preview application to display it.
Quit MathPaper.
It’s that simple — no additional programming is required for printing!
[35] For more detailed control over document printing in a document-based application, use the printDocument: method instead of the print: method.