Thank you for the details and the time this morning, David.

I'm going to summarize the situation and the possible workarounds in VFP8 here.

In VFP, it is possible to set up a non-default page size, as part of printer setup, either from SYS(1037), the native _MFI_PGSET menu bar, or from a custom dialog such as the one described here (this link provides a description of the custom dialog that David uses):

http://news2news.com/vfp/?group=-1&function=425

IOW, VFP will allow you to designate any allowable page size for a given printer.

If you do this as part of report design, you will be able to design your report layout according to the page specifications you have set. If the page height (or width) is greater than the default page size for this printer, you can still design the report accordingly.

NB: custom forms are included in this behavior. If your system and your printer support custom form sizes, these sizes may appear in the setup dialogs, and you can choose them like any other page size.

However, neither runtime report behavior (REPORT FORM PRINT/PREVIEW) nor PRTINFO() seem to make use of non-default page dimensions.

This is why, having designed the report as described above, with a large print size, you may receive the error " too big to fit on page".

A general workaround for this problem in large-size reports is to create a named printer setup where the *default* page size is the one you're after. (Make sure that, when you set up this printer setup in Windows, you put the relevant page sizes every place you can find it -- this is different for different printers <s>. Also I like to make sure that I share the printer with same share name.)

At runtime, you can SET PRINTER TO NAME and now your custom dimensions will be available to the report; the error will not occur.

If you use custom forms, you can assign your custom form as the default page size (using any custom-form-capable printer on the target system) in a named printer setup. In this way your custom dimensions will be available; it doesn't matter to VFP that the custom form might have a different ordinal number (PRTINFO(2)) on different target systems.

If, as David does, you generate your report at runtime with different sizes, based on the user's setup choices in a printer dialog, you have a couple of options:

1) Error trap. In VFP 8 you can trap for the relevant error in the REPORT FORM command. You can tell the user that they picked a page size bigger than the default for this printer and give some options.

2) Compare the default page dimensions for this printer to the ones the user chose.

It would be nice if we could do this using PRTINFO() but we can't.

PRTINFO(3) and PRTINFO(4) only provide information if PRTINFO(2) returns -1 (the printer is not able to give an ordinal page size). In addition, they really only give you access to the default page size, as far as I can see.

However, you can get the page dimensions for both the default and currently-chosen page sizes in one of the following ways:

*a -- with Christof's struct handling as described in http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q304639 or

*b -- with direct Windows API calls and some bit-twiddling, or

*c -- using a custom dialog such as the one referenced in the link above, which does (b) for you.

If the page dimensions the user chose are bigger than the ones in the printer's default page size, give the user some additional options or information and generate your report accordingly.

HTH,

>L<