(2nd Email from Lisa:)

OK, let's look at this quickly...

As before, you may re-post if you re-post in full.

Two major issues and one possible difficulty...

1. I think your outputpage method is going to fail unless you do at least one of the following two things:

a) use the first set of coordinates (the next four params you've left out). Not positive about this part, but...

b) handle your print job properly!! It's *your* print job now. You have to manage it.

Background info: The reportlistener method is only called OutputPage because, with each call, you're asking for, um, an image of a page to be output. (unless you use the clip region params -- in which case you're still asking for a region of a *page*).

VFP doesn't know anything about this printjob, what state the printer is currently in, or what constitutes a page in it. VFP isn't giving the printer any additional, extraneous instructions (such as "this is a page, watch out, here comes a page") to this printjob.

VFP is just outputting something (which *happens* to be the contents of an FRX page) to some device. As far as VFP knows, you could be printing a second layer on top of some page which you're in the process of constructing.

Translation: You need to "embrace" the full printing job with StartDoc and EndDoc calls, and embrace each OutputPage instruction with StartPage and EndPage. This part is actually very straightforward.

2. I don't think your method of giving instructions to the printer (for your multiple bins etc) is right.

Several reasons, most of which boil down to the same advice I gave you earlier: You should use SYS(1037) to *save* the information to a table. But you can't, in your situation, use SYS(1037) to get the results *out* of the table", except to affect the VFP's idea of printer setup . You need to massage the hDC to give those instructions yourself -- using the table that you prepared earlier with SYS(1037).

a) You don't get a DC based on SET PRINTER TO NAME and SYS(1037). And, even though you're comfortable in the HP zone, your CreateDC shouldn't use WINSPOOL explicitly like this.

You want to go into the table of instructions you've created earlier with SYS(1037) and pick up the device and driver information from there for your CreateDC call, you really do.

b) More importantly, I don't think you should use CreateDC like this in between reports. It's one print job. Get the DC once. Then use ResetDC between reports. The FRX (or row in the table of instructions you saved with SYS(1037)) contains the appropriate information for the ResetDC arguments.

c) When I say "table of instructions", I mean the ersatz FRX that I use, which has one record for each saved printer setup that I prepared using SYS(1037). I haven't personally tried saving the instructions into each FRX and then pulling them out from each individual FRX, as you're doing -- but this part should work okay I think.

3. I probably don't understand how or why you are using NOPAGEEJECT here. If it works, it works.

If you do want to use a single listener like this, if I were you, I would not try to do the OutputAllPages() in between the report runs like this -- I would just store the values of listener.PageNo until I was all done, and then output all pages at the end. using my saved pagenumbers as a guide for between which pages I should issue more ResetDC information.

I just have a feeling (since I am not testing this) that it would have less possibility of interfering with whatever is going on internally with NOPAGEEJECT.

See, with listenertypes 1 and 3, outputpage-as-a-method-call is supposed to be available *after* the report run. Even with multipage tiffs, where there is an optimization (as doc'd) when you use the call in AfterReport, I have never tried using OutputPage in AfterReport *except* when the report run is fully ended (translation: (NOT THIS.CommandClauses.NoPageEject)). I don't know if it works or not, and am not tempted to try <g>.

>L<