TweetFollow Us on Twitter

January 94 - Printing in MacApp 3.0.1

Printing in MacApp 3.0.1

Rich Gillam

Several years ago, when I worked at ElvisWare (obviously not their real name), one of the principals of the firm was a guy with a really strong sales background. He had little technical concept, although he thought he knew what he was talking about, and he had a real "promise them everything, but give them ElvisWare" approach to talking to potential customers. It was amazing sometimes the things he'd tell people our next great product was going to do.

But the thing that always stands out was one pet phrase of his: "It's only a couple lines of code, right?" Usually he'd ask us this just after telling someone that one of our database-related products would have a multi-user capability, or something else like that. Sometimes, he'd come in with pseudocode he'd written to prove that it would be easy, things like

#define multiuser              true

and then wonder why the developers were all laughing.

As you can imagine, that made me pretty wary of the phrase "it's only a couple lines of code." So naturally, when I started reading the MacApp documentation and got to the printing section, which seemed to read suspiciously close to "it's only a couple lines of code," I was skeptical.

"it's only a couple lines of code"

So let's take a look at just what you get for your couple lines of code. Figure 1 shows a fairly typical-looking spreadsheet/database-style report window. We have two grid views, one representing the list and one representing the column headings. Each grid view is contained in a scroller, the list in a TPrimaryScroller and the column headings in a TSecondaryScroller, and the TPrimaryScroller has two TScrollerScrollBars hanging off of it. Finally, there's another view across the top that represents a heading of some type.

The MacApp documentation implies that all you have to do is attach a TStdPrintHandler to the view you want to print and life is happy. In fact, they intimate you probably won't even need to subclass it to do most things. So you go into AdLib and attach a TStdPrintHandler to the list view. After adding the macroDontDeadStrip call to your main routine, recompiling, and relinking, you run the program again. Sure enough, the Print command on the menu is now enabled. You choose it, get the Standard Print Dialog, and click OK. The Print Monitor window opens, your printer whirs, and you're feeling good. Maybe printing in MacApp really is that easy.

Then you go and get the page out of the printer. What you've got looks like Figure 2. Like pretty much everything else in MacApp, there's a lot more to this printing stuff than meets the eye.

You wanted something like the window, where the column headings appeared over the list, and the right column headings were repeated on every page. The heading view across the top of the window should have been printed on every page as well. Instead, all you got was the data in the list itself. Pretty bare bones. Pretty much what you'd expect for a few lines of code.

Maybe you attached the print handler to the wrong view. You go back and attach it to the window and try again. Now you get Figure 3. All of the views are there now, but you've gotten only the parts that are showing on the screen, and you also printed the scroll bars. In fact, what you have now looks suspiciously like a screen shot, except that the window frame didn't print. Now you're sure: Maybe MacApp's printing is just a little too WYSIWYG. If you want output that's truly tailored to the printed page instead of the screen, you're going to have to write more than a couple lines of code. In this article, we'll try to cover this situation and some others and look at some of the more common things you might want to do when you print, and how you might do them in MacApp.

disclaimer

Before I go on, a quick disclaimer. There is without question more than one way to do just about everything I'm going to talk about here. I'm not going to profess that my suggestions are the best or the most object-oriented ways of achieving these results. But they work; I'm using them in my current project. In almost all cases, the example code was written especially for this article, based on actual production code. It has not been tested and may have developed errors in the process of making it generic. Take the example code as basically being for illustrative purposes only. If you have improvements or criticisms, I'd like to hear them so I can improve this stuff.

Headers and footers

Probably the most common thing people will want to add to a document when they print it are headers and footers. Even the simplest of documents probably benefits from the addition of page numbers. Fortunately, headers and footers really are quite easy to do in MacApp.

Say, for example, that you want each page of your document to have a footer like the one shown in Figure 4. One way to do this is to override TStdPrintHandler: :AdornPage(). the TStdPrintHandler defines four rectangles that it uses to keep track of different parts of the page. These are stored collectively in a struct called fPageAreas. theInk represents the entire printable area of the page, and its upper left-hand corner is always at (0, 0). thePaper represents the whole page, including the non-printable area, relative to theInk. It will always be either the same size as theInk (in which case they're equal), or bigger, in which case its upper left-hand corner will have negative coordinates. theInterior represents the area within theInk where the view attached to TStdPrintHandler will actually be drawn. theMargins defines the difference between theInk and theInterior, with the default being an inch (72 pixels) on each side. Note that because theInterior.right and theInterior.bottom are less than theInk.right and theInk.bottom, theMargins.right and theMargins.bottom are always negative (this got me at first). The margins, then, are the part of theInk not occupied by theInterior.

When AdornPage() is called, the print handler has already taken care of setting up all the coordinate systems and clipping for you. You are focused on theInk and can draw anywhere within that rectangle in that rectangle's coordinate system. Your AdornPage() method, then, doesn't have to worry about focusing or anything like that; it just has to draw, as a TView::Draw() override would. The only difference is that instead of calling this->GetExtent() to find your bearings, you would refer to fPageAreas.theInk.

So the code to draw Figure 4 would look something like this:

TMyPrintHander :: AdornPage()
{
    VRect           marginRect, footerRect;
    VPoint          offset(0, 0);
    TextStyle       footerTextStyle;
    long            dateTime;
    CStr255         text;
    FontInfo        fontInfo;
    
    // load up the proper text style and measure it
    MAGetTextStyle(kFooterTextStyle, footerTextStyle);
    SetPortTextStyle(footerTextStyle);
    GetFontInfo(fontInfo);
    
    // figure out where we're going to draw (centered
    // vertically, pulled in 1/2 inch from the edge
    // horizontally)
    marginRect = fPageAreas.theInk;
    marginRect.top = fPageAreas.theInterior.bottom;
    footerRect = marginRect;
    footerRect.bottom = footerRect.top + fontInfo.ascent +
        fontInfo.descent + fontInfo.leading;
    offset.v = (marginRect.GetLength(vSel) - footerRect.
        GetLength(vSel)) / 2;
    footerRect += offset;
    offset = VPoint(5, 0);
    footerRect.Inset(offset);
    
    // draw the footer
    MoveTo(footerRect.left, footerRect.top - 1);
    LineTo(footerRect.right - 1, footerRect.top - 1);
    
    GetDateTime(dateTime);
    IUDateString(dateTime, longDate, text);
    MoveTo(footerRect.left, footerRect.bottom);
    DrawString(text);
    
    NumToString(fFocusedPage, text);
    MAParamText("#", text);
    GetIndString(text, kPrintingStrings, kPageNumberString);
    MAReplaceText(text);
    MoveTo(footerRect.right - StringWidth(text), footerRect.bottom);
    DrawString(text);
}

That's all there is to this. Note, by the way, that you can get the current page number from the fFocusedPage instance variable of TStdPrintHandler.

You can also do this kind of thing with a page adorner. I prefer this method because it allows me easier access to TStdPrintHandler's instance variables, and because it makes life easier when you're doing more complicated types of drawing.

Putting a header on the first page

What if you only want the header to appear on the first page? Well, if it's something simple and you can print it in the margins, you can do something like what we did above: Have your AdornPage() method do the drawing, and just test fFocusedPage to see what page you're on.

But if you want to do something more exotic, it takes more work. If you want the header to appear in the page interior, as you might if the header is of variable height, or if the header is already implemented as a view in a window somewhere (one good example is an email message with a distribution list and the message text in different panels), you have to use a more complicated approach.

It's basically not worth the trouble to try and do this kind of printing with the views in the window. Instead, create a new view hierarchy resource that defines exactly how you want things to print. In the example I gave above, you have two views which size horizontally to meet the page and vertically to hold their contents, and they're stacked on top of each other. So you draw a view hierarchy like that, making each view sizePage horizontally and sizeVariable vertically.

Every view hierarchy needs a single view to form the top of it, so we need a containing view. This will be the view the print handler is actually going to print. MacApp gives us no way to define algorithmic positioning of views (enabling us, for example, to keep controls in the window's lower-left corner without writing code), nor do they give us a sizeRelSubViews size determiner. We have to do these things ourselves.

TExpandingView

I created a class to manage this type of window. The work of this view is done in two places: CalcMinFrame(), which figures out how big the view is based on its subviews, and SubViewChangedFrame(), which moves the views around when one of them changes size. They look like this:
pascal void TExpandingView :: CalcMinFrame( VRect& minFrame)
{
    VHSelect            vhs;
    
    // start out with the view's current size (since it
    // won't change in one direction)
    this->GetFrame(minFrame);

    // then do the following for each direction
    for (vhs = vSel; vhs <= hSel; vhs++) {
        if (fSizeDeterminer[vhs] == sizeVariable) {
            CSubViewIterator    iter(this);
            TView*              curView;
            VRect               frame;
            VCoordinate         accumSize = 0;
            VCoordinate         difference;
            
            // add up the sizes of all the subviews in the
            // current direction
            for (curView = iter.FirstSubView(); iter.More(); 
                    curView = iter.NextSubView()) {
                curView->GetFrame(frame);
                accumSize += frame.GetLength(vhs);
            }

            // remember how big everything was before
            this->GetFrame(frame);
            difference = frame.GetLength(vhs) - accumSize;
            accumSize = 0;

            // recalculate the sizes of all the subviews, and
            // add up their sizes again
            for (curView = iter.FirstSubView(); iter.More(); 
                    curView = iter.NextSubView()) {
                curView->AdjustFrame();
                curView->GetFrame(frame);
                accumSize += frame.GetLength(vhs);
            }

            // then add the new total size to the difference of
            // the old total size and the old frame size
            // and make that the new frame size
            if (vhs == vSel)
                minFrame.bottom = minFrame.top + accumSize +
                                    difference;
            else
                minFrame.right = minFrame.left + accumSize +
                                    difference;
        }
    }
}

pascal void TExpandingView :: SubViewChangedFrame(
                TView*              theSubView,
                const VRect&    oldFrame,
                const VRect&    newFrame,
                Boolean             /*invalidate*/)
{
    VHSelect            vhs;
    VPoint              oldSize, newSize;
    VRect               myOldFrame, myNewFrame;
    VCoordinate         difference;
    
    // remember how big we were before
    oldSize = newSize = this->fSize;

    // then, for each direction, bump our size by the
    // amount the subview changed 
    for (vhs = vSel; vhs <= hSel; vhs++) {
        if (fSizeDeterminer[vhs] == sizeVariable) {
            difference = newFrame.GetLength(vhs) -
                                oldFrame.GetLength(vhs);
            newSize[vhs] += difference;

            // move all the subviews according to the
            // difference
            CSubviewIterator    iter(this);
            for (curView = iter.FirstSubView(); iter.More(); 
                    curView = iter.NextSubView()) {
                if (vhs == vSel) {
                    if (curView.top > theSubView.bottom)
                        curView->fLocation.v += difference;
                }
                else {
                    if (curView.left > theSubView.right)
                        curView->fLocation.h += difference;
                }
            }
        }
    }

    // signal the frame change to the parent view,
    // if necessary
    if (oldSize.h != newSize.h || oldSize.v != newSize.v) {
        this->GetFrame(myOldFrame);
        this->fSize = newSize;
        this->GetFrame(myNewFrame);
        if (fSuperView != NULL)
            fSuperView->SubViewChangedFrame(this, myOldFrame,
                                myNewFrame, false);
    }
}

The parent view is then a TExpandingView. To tell this view which is the expanding direction, set the size determiner for that direction to sizeVariable and the size determiner for the other direction to anything other then sizeVariable. Be warned that the code above is designed to deal with the simplest case only: a series of views stacked in a single direction. It will barf on a view hierarchy where you have views that are next to each other in the direction you want it to expand, or where you want it to expand in both directions.

Creating and using a printing view hierarchy

The other part of this is where you create this new view hierarchy. I did this by overriding TStdPrintHandler's Print() method. Attach the print handler to the content view of the window you're printing. Then, in the Print() method, before calling the inherited Print() routine, save off your fView parameter (that content view), call gViewServer->DoCreateViews() to create the printing view hierarchy, set fView to point to it, and call the new view's AddBehavior() method to attach it to the print handler (you don't have to remove it from the view it was attached to). Now call the new view's AdjustFrames() method twice (because the vertical dimension of a text view depends on its width and MacApp calculates the height before the width, you have to call AdjustFrames() twice, once to get the width right and again to get the height right). Then you call inherited.

After the inherited call, you remove the print handler from the printing view hierarchy with RemoveBehavior(), restore fView to its original value, and throw away the printing view hierarchy. It all looks like this:

pascal void TMyPrintHandler :: Print(
        CommandNumber       itsCommandNumber,
        Boolean&        proceed)
{
    TView*              view = NULL;
    TView*              saveView;

    // remember our original view
    saveView = fView;
    
    // create a special view hierarchy for printing, and
    // make it the view this print handler is attached to
    view = gViewServer->DoCreateViews(fDocument, NULL,
                        kTextWindowPrintVH, VPoint(0, 0));
    fView = view;
    view->AddBehavior(this);
    
    // calculate the right view sizes
    view->AdjustFrame();
    view->AdjustFrame();

    // call inherited to actually do the printing
    inherited :: Print(itsCommandNumber, proceed);

    // and restore the old hooks
    view->RemoveBehavior(this);
    view->Free();
    fOwner = (TEventHandler*)(fView = saveView);
}

page breaking

Page breaking is actually one of the areas where the MacApp documentation is relatively decent, but I'll cover it here in the interest of completeness.

Again, if you just use the generic TStdPrintHandler attached to a view without any enhancement on your part, you'll likely discover that page breaks come in places where you don't really want them. There are two primary ways to fix this, depending on the type of view you're printing.

If the view has the possible locations for page breaks occurring at regular intervals (such as for the rows in the chart in Figure 1), you can get by pretty simply. All you have to do is override TView::DoCalcViewPerPage() in your TView subclass. The way I usually do this is to call the inherited DoCalcViewPerPage() first to figure out where the page break would go if you weren't concerned about breaking lines. DoCalcViewPerPage returns a VPoint that shows how many pixels of the view in each direction can be printed on a page. Take the value returned to you by the inherited method, and decrement it by itself modulo the height of a row. For the chart example, that would look something like this:

pascal void TMyView :: DoCalcViewPerPage(  VPoint&
                viewPerPage)
{
    inherited :: DoCalcViewPerPage(viewPerPage);
    if (viewPerPage.v % this->GetRowHeight() != 0)
        viewPerPage.v -= viewPerPage.v %
                            this->GetRowHeight();
}

You'll have to do that calculation in each direction you have regular page breaks.

If you have irregular page breaks, such as the columns in the chart in Figure 1, the job is a little more complicated. Instead of overriding DoCalcViewPerPage(), you override DoBreakFollowing(). DoBreakFollowing() takes two parameters, a direction and the location of the last page break calculated by DoBreakFollowing(), and returns the location of the next page break in the view's coordinate system and a flag telling whether it was algorithmically generated or placed by the user.

In the chart example in Figure 1, you would go through and accumulate columns until you find the position of previousBreak. Then you accumulate column widths after previousBreak until the total is greater than the print handler's fViewPerPage field in the direction you're going (fViewPerPage is what DoCalcViewPerPage() calculated: the maximum number of pixels worth of view content that can be printed on the page). For our chart example, DoBreakFollowing() would look something like this:

pascal VCoordinate TMyView :: DoBreakFollowing(
                VHSelect            vhs,
                VCoordinate         previousBreak,
                Boolean&            automatic)
{
    register short      i;
    VCoordinate         returnVal;
    VCoordinate         viewPerPage;
    VCoordinate         firstOnPage;
    VCoordinate         colWidth;
    
    // this routine shouldn't have to worry about
    // horizontal page breaks
    if (vhs == hSel)
        return inherited :: DoBreakFollowing(vhs,
                            previousBreak, automatic);
        
    // figure out the maximum number of pixels on the page
    // (so we know what fits)
    viewPerPage = this->GetPrintHandler()->fViewPerPage.h;
    
    // loop through the columns
    returnVal = 0;
    firstOnPage = -1;
    for (i=1; i <= NumberOfColumns(); i++) {
        
        // keep track of where the first break on the page in
        // question is
        if (returnVal >= previousBreak && firstOnPage == -1)
            firstOnPage = returnVal;
        
        // if the column we're on won't fit entirely on the
        // current page (if we're up to that page yet), break
        // out of the loop (which will put the break before
        // it); if the column we're on is of 0 width, skip it
        // and go on to the next one
        colWidth = this->GetColWidth(i);
        if (colWidth == 0)
            continue;
        if (firstOnPage != -1 && (returnVal + colWidth) -
                            firstOnPage > viewPerPage)
            break;
        
        // otherwise add this column's width to the total and
        // advance to the next column
        returnVal += colWidth;
    }
    if (i > NumberOfColumns())
        returnVal = fSize.h;
    
    // return the right coordinate of the last column to
    // fit on the page in question, unless that column is
    // too wide to fit on the page by itself, in which case
    // we go ahead and divide it
    automatic = true;
    if (returnVal > previousBreak && NumberOfColumns()
                        != 0)
        return returnVal;
    else
        return previousBreak + viewPerPage;
}

A couple caveats: First, keep in mind that the vhs parameter refers to the direction the page breaks run, not to the direction you're moving through the view to find the page break positions (i.e., page breaks between columns are vertical page breaks). Second, if this routine somehow gets out of sync between calls to get different page break positions, you'll generate ProgramBreak() messages out the wazoo in MacApp.

Now, of course, you need to tell the print handler whether the page breaks are regular or irregular in each direction. IStdPrintHandler() has parameters for this. When you set up the print handler, pass true for itsHFixedSize or itsVFixedSize if the page breaks in that direction come at regular intervals and false if they don't. (Here, true to form, things are backwards from how they are in DoBreakFollowing(): itsHFixedSize controls whether vertical page breaks are regular, and itsVFixedSize controls whether horizontal page breaks are regular.) Note, by the way, that because IStdPrintHandler() takes a bunch of different parameters from IBehavior(), it's probably not a good idea to add the print handler as a behavior in Ad Lib or IcePick. If you do, you'll still have to go back, find it, and set up these parameters manually in your code.

Of course, if you use the TExpandingView, you now have to have it manage page breaking for all of its subviews. It would be nice to have the subviews be responsible for managing page breaks in their own territory and just let the TExpandingView manage the boundary conditions. You can do that as follows:

pascal VCoordinate TExpandingView :: DoBreakFollowing(
            VHSelect        vhs,
            VCoordinate     previousBreak,
            Boolean&    automatic)
{
    VHSelect        ortho;
    
    ortho = gOrthogonal[vhs];

    // we only worry about page breaking in the direction
    // we're sizeVariable
    if (fSizeDeterminer[ortho] != sizeVariable)
        return inherited :: DoBreakFollowing(vhs,
                            previousBreak, automatic);
    
    // if we only have one subview, pass the call on to it
    // (this assumes it isn't inset or offset much from
    // this view)
    if (fSubViews->GetSize() == 1) {
        TView*              subView;
        VCoordinate         returnVal;
        VRect               frame;
        
        subView = (TView*)fSubViews->At(1);
        if (previousBreak != 0)
            previousBreak -= subView->fLocation[ortho];
        subView->GetFrame(frame);
        returnVal = subView->DoBreakFollowing(vhs,
                            previousBreak, automatic);
        returnVal += subView->fLocation[ortho];
        if (returnVal == frame[botRight][ortho]) {
            this->GetExtent(frame);
            return frame[botRight][ortho];
        }
        else
            return returnVal;
    }
    
    // otherwise, we need to iterate through the subviews
    // to break the page
    else {
        CSubViewIterator        iter(this);
        TView*                  subView;
        VRect                   frame;
        VCoordinate             curBreak;
        VPoint                  saveViewPerPage;
        TPrintHandler*          printHandler;
        
        // first, figure out which subview contains
        // previousBreak
        for (subView = iter.FirstSubView(); iter.More();
                            subView = iter.NextSubView()) {
            subView->GetFrame(frame);
            if (frame[topLeft][ortho] <= previousBreak &&
                                frame[botRight][ortho] >=
                                previousBreak)
                break;
        }
        
        // do DoBreakFollowing() on the subview
        if (previousBreak != 0)
            previousBreak -= subView->fLocation[ortho];
        curBreak = subView->DoBreakFollowing(vhs,
                            previousBreak, automatic);
        curBreak += subView->fLocation[ortho];
        
        // for as long as the current break is not within the
        // current view, go on to the next view, doctor it to
        // take care of the amount of the current page taken
        // up with previous views, and do DoBreakFollowing()
        // on it to get the next current-break position
        printHandler = this->GetPrintHandler();
        while (curBreak >= frame[botRight][ortho] &&
                            iter.More()) {
            subView = iter.NextSubView();
            if (subView == NULL)
                break;
            subView->GetFrame(frame);
            saveViewPerPage = printHandler->fViewPerPage;
            printHandler->fViewPerPage[ortho] -= curBreak -
                                previousBreak;
            curBreak = subView->DoBreakFollowing(vhs, 0,
                                automatic);
            curBreak += subView->fLocation[ortho];
            printHandler->fViewPerPage = saveViewPerPage;
        }
        
        // eventually, we'll either get the break in the
        // middle of a view or reach the end of the last
        // subview.  In either case, we return the value of
        // curBreak
        return curBreak;
    }
}

One other instance variable of TStdPrintHandler you might be interested in: TStdPrintHandler::fPageDirection controls which direction the page numbers go in when the view must be split across multiple pages in both directions. If this is set to vSel, pages print columnwise (the first column of pages prints before any pages from the second column). If it's set to hSel, pages print rowwise (the first row of pages prints before any pages from the second row). The default is vSel (columnwise). If you want the pages to print rowwise (which works better in chart-like views), you have to reset fPageDirection in your Initialize() override.

varying the way the view draws

Earlier, we talked about how to set up a special printing view hierarchy. But in a lot of cases, although the view should look a little bit different when you print it, the changes you're making to it seem to be too minor to create a whole new view subclass and go to the trouble of bringing up a printing view hierarchy. Depending on what you're trying to do, there are two ways around this problem.

One of the most common cases is where you want the size determiners to be different. When you show something on the screen, maybe it's sizeSuperView. When you print it, you want it to be sizePage. The easiest way to do this is to override the print handler's Print() method. Get fView's size determiners and save them off in instance variables, set them to the desired values for printing, call the view's AdjustFrame() method so the new size determiners "take", call inherited to do the actual printing, and restore the old size determiners.

In many other cases, you want to change the actual drawing of the view. For instance, maybe your window has controls you don't want to show up in the printed document. Or you used Geneva on the screen because it looks better and want to print in Helvetica because it looks better. Here, you need to alter the view's drawing code so that it does one thing when you're printing and another when you're drawing on the screen. MacApp provides the gPrinting global variable for just this sort of thing. Just test gPrinting to determine which kind of drawing you want to do.

using a view as a header on every page

But in all of this, we haven't really touched on how to print the example we started the article with. Here, you have a view which should print as a header on every page, sized properly to fit the page and another view which also should print on every page, but which needs to be adjusted to match the positioning of the main content view on each page (so the heading line up with their columns). Doing this kind of thing is more tricky:

First, we want to reserve additional space in the margins for the header view. This way the data and the column headings both print inside the area originally defined by theInterior. To do this, your print handler's I method should locate each header view in the window and add their height to fMargins.top. Use a temporary variable to hold the new margin values (initialize it from fMargins), and pass it to TStdPrintHandler::InstallMargins() rather than setting fMargins directly.

Now we're going to tap into AdornPage() to actually draw the views. We'll start with the column headings. I have a routine which is called by my AdornPage() override that draws the column headings. It does essentially what TStdPrintHandler::DrawPageInterior() does to draw the main view. But because the print handler is set up only for drawing the view that represents the page interior, we have a lot of additional grunt work to do.

First, the print handler's Print() override needs to find the column heading view and call its BeInPort() method so that the view thinks it's supposed to draw into the Printing Manager's grafPort. That call would look like this:

fColHeadView->BeInPort((GrafPtr)fPPrPort);

The fPPrPort field has already been initialized by MacApp to point to the Printing Manager's grafPort.

pascal void TMyPrintHandler :: DrawColumnHeadings()
{
    VRect           workRect;
    CRect           qdRect;
    TView*          saveView;
    VRect           clipRect(fPageAreas.theInk);
    VRect           viewExtent;
    
    // refocus on the page border, since God knows what we
    // may be focused on coming into this routine
    this->FocusOnBorder();
    
    // figure out where to draw it
    workRect = this->fPageAreas.theInterior;
    workRect.bottom = workRect.top - 1;
    workRect.top -= fColHeadView->fSize.v + 1;
    fView->ViewToQDRect(workRect, qdRect);
    
    // now set up the print handler as though the col-head
    // view was the view this is set up to print, and
    // arrange all the coordinate systems accordingly
    saveView = fView;
    fView = fColHeadView;
    fQDOrigin.v = -qdRect.top;
    fQDOrigin.h = (short)(fPageAreas.theInk.left +
                        gPageOffset[hSel]);
    SetOrigin(fQDOrigin.h, fQDOrigin.v);
    fColHeadView->UpdateCoordinates();
    clipRect.left += gPageOffset[hSel];
    clipRect.right = fViewedRect.right;
    fColHeadView->ViewToQDRect(clipRect, qdRect);
    ClipRect(qdRect);
    fQDRectToClipTo = qdRect;
    
    // use HandleDraw() to draw the view's contents
    fColHeadView->GetExtent(viewExtent);
    fColHeadView->ViewToQDRect(viewExtent, qdRect);
    fColHeadView->HandleDraw(qdRect);
    
    // and restore the print handler's view pointer
    fView = saveView;
}

Here's what we're doing: First, we call the print handler's FocusOnBorder() method. MacApp calls this for us before calling AdornPage(), but if we're doing other view drawing in here (such as the main header view), we might not still be focused on the border by the time we get here, so we reset it to make sure. Now figure out where on the page the column headings are supposed to go. The rectangle that contains them will be directly above the page interior rectangle, the width of the page interior, and the height of the view (which is fixed). Translate that into QuickDraw coordinates.

Now save off the print handler's fView field and set fView to point to the column heading view. Now we have to set all of the print handler's other fields as though the column heading view were the view we always print. fQDOrigin is the location, relative to theInk, where the printing port's QuickDraw origin should go. In the vertical direction, that spot is always the same: the upper left-hand corner of the rectangle we got above. In the horizontal direction, we move with the main view. gPageOffset is the distance from the view's origin to where this page's part of the view is. This is what causes the column headings to line up horizontally with the data in the chart. Once we've calculated fQDOrigin, call SetOrigin() to put it into effect in the print port. Then call the view's UpdateCoordinates() method so that its internal values match the ones we've set up for the print handler.

Finally, we set up fQDRectToClipTo, which causes only the part of the view that is actually supposed to print on the current page to do so. Vertically, we can clip to theInk. Horizontally, the left boundary is gPageOffset.h again and the right boundary is determined by fViewedRect, which has been set up by the page-breaking code.

Now we can call the view's HandleDraw(), which will take care of the remaining coordinate setup and clipping for us and draw the view's contents (along with all its adorners and subviews). And all we have to do to clean up is restore fView to its original value.

Printing the main heading view is almost the same, but there are some important differences. This view needs to be sized according to the width of the page, and the whole view is printed on every page, rather than being offset according to the stuff in content area of the page. To accomplish the resizing, we do the trick I described above: in the Print() method, save off the view's original size determiners, set the horizontal size determiner to sizePage, and call AdjustFrame(). Then restore the original size determiners after the call to inherited.

In the printing code, we do exactly what we did above, with a few exceptions: We have to offset workRect by the height of the column-heading view so that the main heading view prints above it. fQDOrigin is fixed at the position on the page where the view is to go, so the lines in the function above that set fQDOrigin can change to

fQDOrigin = gZeroPt - qdRect[topLeft];

Likewise, all we have to do to set up fQDRectToClipTo is translate theInk into QuickDraw coordinates:

fIconInfoView->ViewToQDRect(clipRect, qdRect);
ClipRect(qdRect);
fQDRectToClipTo = qdRect;

Everything else about drawing the main heading view is the same.

More than a few lines of code

As you can see, truly robust printing in MacApp involves more than "a few lines of code". Hopefully, this article gives a good introduction to some of the techniques that are common in printing real-world documents with MacApp. MacApp really does do a good job of providing the basics. All you really have to do is fill in the gaps. I hope that the "more than a few lines of code" in this article can give you a good start.
 
AAPL
$102.13
Apple Inc.
+1.24
MSFT
$44.87
Microsoft Corpora
-0.14
GOOG
$571.00
Google Inc.
-6.86

MacTech Search:
Community Search:

Software Updates via MacUpdate

Get Lyrical 3.8 - Auto-magically adds ly...
Get Lyrical auto-magically add lyrics to songs in iTunes. You can choose either a selection of tracks, or the current track. Or turn on "Active Tagging" to get lyrics for songs as you play them.... Read more
Viber 4.2.2 - Send messages and make cal...
Viber lets you send free messages and make free calls to other Viber users, on any device and network, in any country! Viber syncs your contacts, messages and call history with your mobile device,... Read more
Cocktail 7.6 - General maintenance and o...
Cocktail is a general purpose utility for OS X that lets you clean, repair and optimize your Mac. It is a powerful digital toolset that helps hundreds of thousands of Mac users around the world get... Read more
LaunchBar 6.1 - Powerful file/URL/email...
LaunchBar is an award-winning productivity utility that offers an amazingly intuitive and efficient way to search and access any kind of information stored on your computer or on the Web. It provides... Read more
Maya 2015 - Professional 3D modeling and...
Maya is an award-winning software and powerful, integrated 3D modeling, animation, visual effects, and rendering solution. Because Maya is based on an open architecture, all your work can be scripted... Read more
BBEdit 10.5.12 - Powerful text and HTML...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more
Microsoft Office 2011 14.4.4 - Popular p...
Microsoft Office 2011 helps you create professional documents and presentations. And since Office for Mac 2011 is compatible with Office for Windows, you can work on documents with virtually anyone... Read more
TextWrangler 4.5.10 - Free general purpo...
TextWrangler is the powerful general purpose text editor, and Unix and server administrator's tool. Oh, and also, like the best things in life, it's free. TextWrangler is the "little brother" to... Read more
BitTorrent Sync 1.4.72 - Sync files secu...
BitTorrent Sync allows you to sync unlimited files between your own devices, or share a folder with friends and family to automatically sync anything. File transfers are encrypted. Your information... Read more
Cyberduck 4.5.2 - FTP and SFTP browser....
Cyberduck is a robust FTP/FTP-TLS/SFTP browser for the Mac whose lack of visual clutter and cleverly intuitive features make it easy to use. Support for external editors and system technologies such... Read more

Latest Forum Discussions

See All

ALONE... (Games)
ALONE... 1.0.1 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0.1 (iTunes) Description: ALONE is a handcrafted, intense survival journey through space. Navigate caves, rip through rocky debris, dodge rocks and comets... | Read more »
Almightree: The Last Dreamer (Games)
Almightree: The Last Dreamer 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: The world is shattering and you are the only hope to restore the balance. A thrilling and challenging 3D puzzle... | Read more »
The Nightmare Cooperative (Games)
The Nightmare Cooperative 1.1 Device: iOS Universal Category: Games Price: $3.99, Version: 1.1 (iTunes) Description: Fiendishly difficult! Adorably cute! Utterly engrossing!How much gold can you get before your entire team is... | Read more »
Mobile Convolution (Music)
Mobile Convolution 1.0.0 Device: iOS Universal Category: Music Price: $9.99, Version: 1.0.0 (iTunes) Description: | Read more »
Invaders! From Outer Space Review
Invaders! From Outer Space Review By Rob Thomas on August 27th, 2014 Our Rating: :: RETRO NOSTALGIAUniversal App - Designed for iPhone and iPad It’s a shame that Invaders! doesn’t offer deeper gameplay, as this retro-inspired... | Read more »
Spooklands Review
Spooklands Review By Jennifer Allen on August 27th, 2014 Our Rating: :: ONE-TOUCH SHOOTERUniversal App - Designed for iPhone and iPad One-touch simultaneously controls your direction and your weapon in this unique arena shooter.   | Read more »
Heroes of Order & Chaos Add Twitch I...
Heroes of Order & Chaos Add Twitch Integration, New Heroes, and More Posted by Ellis Spice on August 27th, 2014 [ permalink ] | Read more »
Foodie Yama Review
Foodie Yama Review By Jennifer Allen on August 27th, 2014 Our Rating: :: BRIEFLY HOOKSUniversal App - Designed for iPhone and iPad Foodie Yama will draw you in for a brief while, and you’ll never be entirely sure why.   | Read more »
Spotify Connect Turns One, Now Supports...
Spotify Connect Turns One, Now Supports New Devices Posted by Ellis Spice on August 27th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
The Rise of PicsaStock and How You Can M...
We all take plenty of photos, right? That’s the joy of having a reasonably powerful camera in your pocket, thanks to your trusty iPhone and a bevy of similarly useful apps. Wouldn’t it be great to make some money out of those snaps? While your... | Read more »

Price Scanner via MacPrices.net

12-Inch MacBook Air Coming in 4Q14 or 2015 –...
Digitimes’ Aaron Lee and Joseph Tsai report that according to Taiwan-based upstream supply chain insiders, Apple plans to launch a thinner MacBook model either at year end 2014 or in 2015, and that... Read more
Sapphire Screen “Most Wanted” iPhone 6 New Fe...
According to the ‘uSell.com iPhone Most Wanted Survey’ — a representative survey of 1,000 U.S. smartphone users conducted by used iPhone marketplace uSell.com — close to half of all smartphone users... Read more
The iPad’s Real Competitive Challenger (Not S...
It’s been my contention for some time that the iPad is suffering from something of an identity crisis, and I suspect that may be a factor in slackening sales this year. Apple can’t seem to decide... Read more
13-inch 2.6GHz/256GB Retina MacBook Pro on sa...
B&H Photo has the 13″ 2.6GHz/256GB Retina MacBook Pro on sale for $1379 including free shipping plus NY sales tax only. Their price is $120 off MSRP. Read more
Life Inventory iOS Apps – Learn to Know Thyse...
James Hollender’s Life Inventory apps s are now on sale with 20% off thru Labor Day, 09/01/2014. This is a great opportunity to get started on that Moral Inventory you’ve been putting off doing for... Read more
Pocket Watch, LLC. Reveals Cloud Server For P...
Beaumont, Texas based Pocket Watch, LLC. has announced the availability of its new ActivePrint Cloud Server Powered by Raspberry Pi. With this small standalone box almost any USB printer or available... Read more
902it Simplifies Area Code Changes For Nova S...
The east coast Canadian provinces of Nova Scotia and Prince Edward Island are phasing in 10 digit telephone dialing, to be fully in place by November, in order to accommodate a second area code to... Read more
Boomerang iPad Stand Mounts Your iPad Anywher...
Boomerang, a Mountable Stand with Multiple Viewing Angles, is now available for iPad Air. Boomerang combines several functions that aim to expand your iPad’s potential in one, elegant product. The... Read more
Retina MacBook Pros available starting at $10...
The Apple Store has Apple Certified Refurbished 13″ and 15″ MacBook Pros available starting at $929. Apple’s one-year warranty is standard, and shipping is free: - 13″ 2.5GHz MacBook Pros (4GB RAM/... Read more
Apple 27-inch Thunderbolt Display (refurbishe...
The Apple Store has Apple Certified Refurbished 27″ Thunderbolt Displays available for $799 including free shipping. That’s $200 off the cost of new models. Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Senior Event Manager, *Apple* Retail Market...
…This senior level position is responsible for leading and imagining the Apple Retail Team's global event strategy. Delivering an overarching brand story; in-store, Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Project Manager / Business Analyst, WW *Appl...
…a senior project manager / business analyst to work within our Worldwide Apple Fulfillment Operations and the Business Process Re-engineering team. This role will work Read more
Position Opening at *Apple* - Apple (United...
…customers purchase our products, you're the one who helps them get more out of their new Apple technology. Your day in the Apple Store is filled with a range of Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.