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.
 

Community Search:
MacTech Search:

Software Updates via MacUpdate

BBEdit 11.1.1 - Powerful text and HTML e...
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
CrossOver 14.1.3 - Run Windows apps on y...
CrossOver can get your Windows productivity applications and PC games up and running on your Mac quickly and easily. CrossOver runs the Windows software that you need on Mac at home, in the office,... Read more
Little Snitch 3.5.3 - Alerts you about o...
Little Snitch gives you control over your private outgoing data. Track background activity As soon as your computer connects to the Internet, applications often have permission to send any... Read more
OmniGraffle Pro 6.2.3 - Create diagrams,...
OmniGraffle Pro helps you draw beautiful diagrams, family trees, flow charts, org charts, layouts, and (mathematically speaking) any other directed or non-directed graphs. We've had people use... Read more
OmniFocus 2.2 - GTD task manager with iO...
OmniFocus helps you manage your tasks the way that you want, freeing you to focus your attention on the things that matter to you most. Capturing tasks and ideas is always a keyboard shortcut away in... Read more
Cocktail 8.4 - 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
PDFKey Pro 4.3 - Edit and print password...
PDFKey Pro can unlock PDF documents protected for printing and copying when you've forgotten your password. It can now also protect your PDF files with a password to prevent unauthorized access and/... Read more
Kodi 15.0.beta1 - Powerful media center...
Kodi (was XBMC) is an award-winning free and open-source (GPL) software media player and entertainment hub that can be installed on Linux, OS X, Windows, iOS, and Android, featuring a 10-foot user... Read more
DiskCatalogMaker 6.4.12 - Catalog your d...
DiskCatalogMaker is a simple disk management tool which catalogs disks. Simple, light-weight, and fast. Finder-like intuitive look and feel. Super-fast search algorithm. Can compress catalog data... Read more
Macs Fan Control 1.3.0.0 - Monitor and c...
Macs Fan Control allows you to monitor and control almost any aspect of your computer's fans, with support for controlling fan speed, temperature sensors pane, menu-bar icon, and autostart with... Read more

Moleskine Timepage – Calendar for iCloud...
Moleskine Timepage – Calendar for iCloud, Google & Exchange 1.0 Device: iOS iPhone Category: Productivity Price: $4.99, Version: 1.0 (iTunes) Description: The most elegant calendar for your pocket and wrist, Timepage is a... | Read more »
QuizUp Gets Social in its New Update
Plain Vanilla Corp has released a new and improved version of their popular trivia game, QuizUp. The app now emphasizes social play so you can challenge friends from all over the world. [Read more] | Read more »
The Deep (Games)
The Deep 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: Swipe Controls Delve into the deep in this retro rogue-like! Swipe to move your diver around and keep away from the enemies as you... | Read more »
Battle of Gods: Ascension (Games)
Battle of Gods: Ascension 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: TURN-BASED TACTICAL COMBATFight tactical battles against the forces of Hades! In Battle of Gods: Ascension you play... | Read more »
Shadowmatic's Latest Update Adds a...
Shadowmatic's shadowy shadow-ness is getting a little shadowy-er thanks to a recent update that adds an Arcade Mode. [Read more] | Read more »
Sunrise Calendar and Slack Have Assimila...
Wunderlist is perhaps one of the most populat and beloved productivity apps on the App Store - and now it's gone and incorporated itself into other useful services like Sunrise Calendar and Slack. [Read more] | Read more »
Crossy Road Devs Hipster Whale are Bring...
Hipster Whale, the minds behind the rather popular (and rather great) Crossy Road, have teamed-up with Bandai Namco to create PAC-MAN 256: an absolutely bonkers looking maze runner chaser thing. | Read more »
Meet the New Spotify Music
Spotify Music  has a lot going on. They're introducing 3 new modes to serve all your musical needs, with the "Now" start page  gives you curated playlists based on your particular tastes. As you listen the app will learn more about your tastes and... | Read more »
What the Apple Watch Gets Right, and Wha...
| Read more »
Celebrate PAC-MAN's 35th Birthday W...
BANDAI NAMCO Entertainment America is celebrating PAC-MAN's 35th anniversary by releasing updates for PAC-MAN and PAC-MAN Lite for iOS. [Read more] | Read more »

Price Scanner via MacPrices.net

Apple refurbished 2014 13-inch Retina MacBook...
The Apple Store has Apple Certified Refurbished 2014 13″ Retina MacBook Pros available for up to $400 off original MSRP, starting at $979. An Apple one-year warranty is included with each model, and... Read more
What Would the ideal Apple Productivity Platf...
For the past four years I’ve kept a foot in both the Mac and iPad camps respectively. my daily computing hours divided about 50/50 between the two devices with remarkable consistency. However, there’... Read more
PageMeUp 1.2.1 Ten Dollar Page Layout Applica...
Paris, France-based Softobe, an OS X software development company, has announced that their PageMeUp v. 1.2.1, is available on the Mac App Store for $9.99. The license can be installed on up to 5... Read more
Eight New Products For USB Type-C Application...
Fresco Logic, specialists in advanced connectivity technologies and ICs, has introduced two new product families targeting the Type-C connector recently introduced across a number of consumer... Read more
Scripps National Spelling Bee Launches Buzzwo...
Scripps National Spelling Bee fans can monitor the action at the 2015 Spelling Bee with the new Buzzworthy app for iOS, Android and Windows mobile devices. The free Buzzworthy app provides friendly... Read more
13-inch 2.5GHz MacBook Pro on sale for $120 o...
B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $979 including free shipping plus NY sales tax only. Their price is $120 off MSRP, and it’s the lowest price for this model (except for Apple’... Read more
27-inch 3.3GHz 5K iMac on sale for $1899, $10...
B&H Photo has the new 27″ 3.3GHz 5K iMac on sale for $1899.99 including free shipping plus NY tax only. Their price is $100 off MSRP. Read more
Save up to $50 on iPad Air 2, NY tax only, fr...
B&H Photo has iPad Air 2s on sale for up to $50 off MSRP including free shipping plus NY sales tax only: - 16GB iPad Air 2 WiFi: $469 $30 off - 64GB iPad Air 2 WiFi: $549.99 $50 off - 128GB iPad... Read more
Updated Mac Price Trackers
We’ve updated our Mac Price Trackers with the latest information on prices, bundles, and availability on systems from Apple’s authorized internet/catalog resellers: - 15″ MacBook Pros - 13″ MacBook... Read more
New 13-inch 2.9GHz Retina MacBook Pro on sale...
B&H Photo has the 13″ 2.9GHz/512GB Retina MacBook Pro on sale for $1699.99 including free shipping plus NY tax only. Their price is $100 off MSRP, and it’s the lowest price for this model from... Read more

Jobs Board

*Apple* Solutions Consultant - Retail Sales...
**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail Read more
*Apple* Watch SW Application Project Manager...
**Job Summary** The Apple Watch software team is looking for an Application Engineering Project Manager to work on new projects for Apple . The successful candidate Read more
Engineering Manager for *Apple* Maps on the...
…the Maps App Team get to take part in just about any new feature in Apple Maps, often contributing a majority of the feature work. In our day-to-day engineering work, we Read more
Senior Software Engineer - *Apple* SIM - Ap...
Changing the world is all in a day039s work at Apple . If you love innovation, here039s your chance to make a career of it. You039ll work hard. But the job comes with Read more
Lead *Apple* Solutions Consultant - Retail...
**Job Summary** Job Summary The Lead ASC is an Apple employee who serves as the Apple business manager and influencer in a hyper-business critical Reseller's store Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.