a "simple" way to detect printing from print preview

[markftwain]

Hi All,

Having read everything I can find (including Mike's FAQ), I can't seem to get a "this report has been printed" flag.

As simple as possible, how do you catch the user printing the report by print preview toolbar and report menu while it was being previewed?

I'm using VFP 9 sp2, Reportbehaviour 90.

Thanks

 

[Mike Gagnon]

The FAQ I wrote does specify "And in the gray band of page header of your report (The fist of three bands)". Not the detail band. That way it only sets the flag once.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Dan Freeman]

Are *any* of you guys testing with REPORTBEHAVIOR 90 (as specified in the very first post in the thread)?

Hence, reportbehavior 80 and reportbehavior 90 do not run identically.

 

[markftwain]

Thank you Dan,

Following Olaf's suggestions, leads me to the following results:

1. With settings of _screen.visible = .f., REPORTBEHAVIOR 90, the report nicely displays--but no preview toolbar. Right click on the previewed report shows the menu for printing. Printing from this menu does NOT change glPrinted values from .f. to .t.

2. With settings of _screen.visible = .t., REPORTBEHAVIOR 90, the report displays with the toolbar. Printing from either the tool bar icon or the menu does not change glPrinted.

3. With settings of _screen.visible = .f., REPORTBEHAVIOR 80, shows ONLY the print preview toolbar--no report page. Clicking on the printer icon correctly prints the report AND changes glPrinted from .f. to .t.

4. With settings of _screen.visible = .t., REPORTBEHAVIOR 80,
shows the print preview toolbar and the report page. Right click on the report does not give the print menu. Printing from the print preview printer icon correctly prints the report AND changes glPrinted from .f. to .t.

So, it looks like I'm stuck with #4 and need to give up the right-click for the menu?

 

[Dan Freeman]

That behavior sounds about right.

With reportbehavior 90, the report is rendered for preview and when you call for printing they just print the already-rendered image. There is no further evaluation of report expressions.

(One of the perpetual gripes about the old print engine was that preview often differed from the printed report.)

Having said that, I don't think you're stuck with reportbehavior 80.

One of the major benefits of reportbehavior 90 is that print preview is a Foxpro class. If it doesn't natively do what you want, subclass it. I believe there's a page on Mike Lewis' site that discusses this. Ah, yes:

http://www.ml-consult.co.uk/foxst-46.htm

 

[markftwain]

Thanks Dan,

Probably not a simple solution, but its good to know my results are reasonable. I guess simple is not always best. Thank you Mike for the excellent article. So off to subclassing we go...

 

[Mike Lewis]

Mark,

Glad you found the article useful.

Actually, you might not need to create a subclass. It should be enough for you just to slightly modify the toolbar object. You'll see that it contains a Print button. Just add your own code to its Click event, to set the flag that tells you the report has been printed.

That way, you can forget about calling an expression from within the report.

(I haven't checked the above in detail, but I think it's right.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[markftwain]

Thanks to all for your help, to conclude, this seems to work correctly for me:

procedure test
set REPORTBEHAVIOR 90

local loPreview
loPreview = null
do (_reportpreview) with loPreview
loPreview.CanvasCount = 2
loPreview.ZoomLevel = 4
loPreview.ToolbarIsVisible = .f.

loListener = createobject"ReportListener")
loListener.previewcontainer = loPreview
loListener.listenertype = 1

* add check for when user prints report
bindevent(loListener,"OnPreviewClose",this,"setprinted")

report form test.frx object loListener

unbindevents(this)
endproc

procedure setprinted ( lprint )
public glPrinted
m.glPrinted = m.lprint
endproc

Bye, Mark

 

[Olaf Doschke]

Hi Mark, Hi Dan,

Sorry, I should have been more careful. I thought testing both reportbehavior 90 and 80, as I thought my default is reportbehavior 90 and I switched to reportbehavior 80, but my default is 80, so I only double tested the old report engine. Yes, I know there is SET("Reportbehavior") to check.

Glad you found out a way via Reportlistener and also show it here. Instead of binding to OnPreviewClose you could also put code into that method in your own reportlistener, especially if that's not the only thing you'd overload in your own reportlistener. It's very plausible to use that method, anyway.

Bye, Olaf.

 

[Dan Freeman]

Bravo, Mark!

I recognize prototype code when I see it, but I feel compelled to comment for readers:

    procedure setprinted ( lprint )
        public glPrinted
        m.glPrinted = m.lprint
    endproc

This will throw an error on the second call because the variable has already been declared public. Either test Type()="U" or explicitly release it before declaring it.

 

[JRB-Bldr]

By using this forum's Search utility and going back in time I came across:

How to determine if the user pressed the print button during preview
faq184-2919
or
Another - Printing a report after preview
thread184-818996

I see above that jimoo has already pointed you to the FAQ.
And markftwain has told you about using the appropriate band in the Report Form.

Won't using one or both of these suggestions accomplish what you need in a MUCH simpler manner?

Good Luck,
JRB-Bldr

 

[Mike Lewis]

JRB-Bldr,

"How to determine if the user pressed the print button during " preview" was the very FAQ that Mark referred to in his original question, and which he says didn't work for him (although, admittedly, he didn't quote the title of the FAQ in his message).

If I've followed this thread correctly, it seems the reason it didn't work for him was that he is using REPORTBEHAVIOR 90, and the FAQ was probably written before that setting was available.

(Although I don't think any of us asked him why he was using REPORTBEHAVIOR 90, but no doubt he had a good reason.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy