Malcolm -

Dorin has given you some good pointers. Let me add my 5c.

I'm building a custom print preview form using a shape for my canvas. [..] I've figured out how to move between pages. This works great! Now I'm trying to figure out how:
1. How to print to a printer given a specific canvas control

You have two choices. Calling Listener.OnPreviewClose(.T.) will cause VFP to print the cached rendered pages to FoxPro's default printer, and no more work from you is required.

You can also manually get a GDI handle to some other printer (I'd have to look up how to do this) and direct selected pages to it by using Listener.OutputPage( nPageno, hGdi, 0 ).

The actual canvas control has nothing to do with the printing process as you've probably figured out.

2. Change the zoom factor of my canvas

To do this accurately requires knowing the DPI of your screen and scaling the shape/container control appropriately. In other words, if your screen is 96dpi and your page is 8.5 x 11 then for 100% zoom your shape must be (8.5x96) by (11x96). Fractional zooms are easy to pull out of that.

It is not so easy to display a zoomed portion of the page in a constant canvas size. Check out the additional parameters on .OutputPage().

3. If I want scrollbars for zoomed in pages, must I add scrollbars to my preview form and resize my preview form and its associated canvas to match my zoom magnification level?

This is the easiest thing to do, and it is what the default preview does.

Or is there a way for VFP to add scrollbars to the canvas itself?

There is no way I know of to get VFP to do it. You can definitely "roll-your-own" scrollable view port - people have done this - but it is a lot of work. It can be done, though.

4. Specify a 2-up page display mode (do I need to add an additional canvas for the 2nd page view?)

It's one canvas/shape per visible page.

5. Is there a way to have VFP return to the current page in preview mode after a report is printed? With the default preview form, VFP always exits preview mode after being asked to print.

I believe there is a technical reason why VFP traditionally required the preview window to be closed when you pressed the PRINT button on the toolbar. In VFP9, the Listener API works the same way - the only way to print the cached pages that were viewed in the preview window is to call .OnPreviewClose(.T.) which - according to the contract between preview and reportlistener, indicates that preview has closed.

(One way of explaining this behavior is to imagine that the ReportListener will dispose of the internal rendered page cache during printing. QED, the preview must not remain open (and potentially call .outputPage() again) after physical printing has occurred. This is pure conjecture, and given my response to question 1) above is probably not correct. Whatever.)

Once you are free from the constraints of duplicating the preview behavior of previous versions of VFP, you don't have to do it this way. If you know what the REPORT FORM command was, you can have your preview UI have a PRINT button that re-issues the command (using a fresh ReportListener instance of course).

One consideration here is that for long reports, this may not be so good if the delay in re-running the report is unacceptable.

I hope this helps,
- Colin