How to pass a param to tell a report to Page Advance vs Line Advance?

[montypython1]

Greetings,

How do I tell a report to Page Advance vs. Line Advance at run time? I would think that I could pass a parameter to do this. I realize that within the Report Designer properties, there is an area called "Data Grouping". And within this area, I can cause a Group to generate either a New Page or a New Line.

What I can't seem to figure out is how to change this on demand (I do not want to maintain 2 separate reports). I suspect that it would look something like this, where there are 4 parameters being passed:
DO ReportPreview IN 01Main WITH "1on1 Report" , "reports\var_all_3ld.frx", "P" , "L"
In the 3rd parameter, the "P" signifies that the first data group should have a Page break. In the 4th parameter, the "L" signifies that the second group should have a Line break. The procedure "ReportPreview" is below (it has 5, not 4 parameters, but you get the idea).

Any ideas how to implement this kind of report flexibility?

Thanks,
Dave Higgins




****************************************************************
*** ReportPreview
*** 20100907
****************************************************************
****************************************************************
PROCEDURE ReportPreview
PARAMETERS RptCaption, RptName, RptForClause, P_L_Group1, P_L_Group2
****************************************************************
oRepForm = CREATEOBJECT("Form")
WITH oRepForm
.CAPTION = (RptCaption) + " - - - - - To Close: either click on the 'Print Preview Toolbar Door' -or- click on the Red 'X' -or- press the 'ESC' button"
.WINDOWSTATE = 2 &&This will maximize the form
.MINBUTTON = .F.
.MAXBUTTON = .F.
.SHOW()
ENDWITH

IF VARTYPE(RptForClause) <> "L"
REPORT FORM (RptName) ;
FOR &RptForClause ;
TO PRINTER PROMPT PREVIEW WINDOW (oRepForm.NAME)
ELSE
REPORT FORM (RptName) ;
TO PRINTER PROMPT PREVIEW WINDOW (oRepForm.NAME)
ENDIF

oRepForm.RELEASE()
****************************************************************
RETURN
****************************************************************
ENDPROC
*****************************************************************************************************
*****************************************************************************************************

 

[Mike Lewis]

Dave,

Off-hand, I can't think of a way of telling the report which kind of break you want. It might be possible to do it by setting up two different groups, using a logical flag which is based on the choice of break, but I can't immediately see how to do that. No doubt one of the bright people in the forum will give you a solution.

What I can tell you is that you should forget about passing parameters to a report.

The way to pass a single value to a report is to store it in a private variable. Do that in the routine that calls the report. If the variable is private, it will be directly visible in the report, and you will be able to refer to it in the report's expressions (including group expressions), "print when" clauses, and so on.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Scott24x7]

Dave,
What printer are you using, and what "language" to talk to the printer?
In the "old days" (Oh my, 16 years ago) I did a lot of FPW26 work with HP printers. I had to, as you can imagine, send all the print to them in "code". So I used HPGL pass from FPW to the printer. There are a series of escape codes (CHR(27) + (code)) that sends "changes" to the printer. You can send rudimentary things like CR, LF, Page Eject using the codes. I don't remember them off the top of my head but a little experimentation should help you. As memory serves they are all ASCII values less 27. So if you have that level control over your app, you may be able to send printer codes to the printer by sending escape sequences.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

By the way, you send commands directly to the printer with:

??? CHR(27)+ASC(14)

Form Feed character (ASCII Value 14)should do it. So if you issues that between your REPORT FORM calls, it may work, or if you put it in a summary "footer" that only prints when the print grouping is done, it may work. (In that case imbed the ASCII value (Use keyboard, place your cursor where you want it, press ALT Key, and while holding it down, enter on the numeric keypad section 14, then release the ALT key.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[JRB-Bldr]

"What I can't seem to figure out is how to change this on demand"

What you don't seem to realize is that once you execute the REPORT FORM command, the VFP Report form is off working on the data in an stand-alone manner. It is not 'open' to accepting interactive commands while in the midst of generating a Report.

You can set up memory variables prior to your REPORT FORM command which can control how the Report Form works. These can be used in the various Print When expressions. Additionally you can manage the data records which you pass to the REPORT FORM by adding extra fields to be used for Report Form management, etc.

From your description..
"In the 3rd parameter, the "P" signifies that the first data group should have a Page break. In the 4th parameter, the "L" signifies that the second group should have a Line break. "
I would suggest that you create a separate set of Report Data Records and manipulate them (add additional 'control' fields, etc.) in whatever manner is necessary prior to passing them to the REPORT FORM and thereby attain your desired results.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Scott,

I also thought of suggesting to Dave that he sends a form feed character (which, by the way, is ASCII 12). The problem is that there is no opportunity to do that. Once you have started the report, the report engine has full control, and you can't interrupt the rendering process to send arbitrary control characters to the printer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Scott24x7]

Mike,
Yeah, sorry I'm rusty. My idea was born out of having to do something like HPGL code, where you could force that kind of thing.
But, I thought the ASCII code could still be put into the footer of a report form, and force a new page when that condition (as JRB mentioned) controlled with a PRINT WHEN.
I'm not a fan of hand writing reports, but sometimes it has to be done.
I've been out of much VFP dev for about 5 years, but recently started a new application build that I need for some research I'm doing. (Still the best tool for stand-alone DB work, IMHO). So I've rejoined the forums, as I found participating in discussion of problems is the best way to immerse and get back on top of the game. Thanks for the clarity!


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[JRB-Bldr]

"I thought the ASCII code could still be put into the footer of a report form, and force a new page when that condition (as JRB mentioned) controlled with a PRINT WHEN."

Actually that's not quite what I was suggesting.

My primary suggestion was to build the Report Data records in such as way and sequenced/indexed as needed so as to control how the Report behaves. If that means adding additional 'control' fields to the Report Data records and utilize them in the Report Form's Group and/or Print When expressions - so be it.

That should eliminate having to be hand writing reports.

Good Luck,
JRB-Bldr

 

[TamarGranor]

This seems like something you could do with a report listener. You could provide info somewhere that the report listener uses to tweak the FRX to get what you need.

Tamar

 

[Olaf Doschke]

In fact a reportlistener has a "EvaluateContents" Event running before each report object. It enables you to change certain attributes, but not the pagebreak of bands unfortunately.

Your chance is to change the frx itself before printing, you need to change the pagebreak field of the frx for all records with objecttype=9 (band) and objectcode=3 (group headers).

You can't change that at run time, even a reportlistener reads in the frx beforehand and you only can peek into a read-only frx copy in the reportlisterner.frxdatasession (see the help topic on the FRXDataSession property).

Bye, Olaf.

 

[Scott24x7]

JRB,
Well, in that case, couldn't you insert a blank record after the last point in the table (assuming your building a "temporary data table" that as the contents of the first field, it contains the ASCII 14, thereby forcing your page to eject?
(So, dress up your data before you print, and let the record drive the page eject).

Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Another possibility might be to add an extra level of grouping to the report. This new level will have its "Group starts on" set to New Page. The existing grouping will have it set to New Line.

You would also need an extra field in the cursor that drives the report. This would be the same data type and size as the field that controls the exisitng grouping.

When you create the cursor, if you want the report to have page breaks, you populate the new field and leave the existing controlling field empty. If you want it to have line breaks, you do the opposite.

I haven't worked out the details, and there might be problems I haven't thought of, but maybe it's worth exploring further.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[JRB-Bldr]

" Well, in that case, couldn't you insert a blank record after the last point in the table (assuming your building a "temporary data table" that as the contents of the first field, it contains the ASCII 14, thereby forcing your page to eject?"

Mike gets what I have been suggesting immediately above.

No, do not try to put an ASCII 14 into the first field since the Report Form will most likely not use it as you expect.

Instead, as I suggested, add an extra 'control' field to the Report Data (example: RptGrp C(1)) - no need for additional records.

Then use that new field to control when you want the page to Eject. Within the Report Form you set up a Group to work on that 'control' field and to Start Each Group On A New Page.

That way, by modifying the values contained in the RptGrp field prior to sending it to the Report Form, you can cause the Report Form to eject a page whenever you want.

Good Luck,
JRB-Bldr

 

[montypython1]

Thank you all for your input. Since this is a little over my head, it will take me a while to try out your suggestions ... I'll let you know how it works.

Thank you again.
Dave