Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Start Grouping band on new page at runtime

Status
Not open for further replies.

KALP1

Programmer
Aug 26, 2016
102
0
0
IN
Sometimes I want to print grouping band in a new page and sometimes continuous. Right now I maintain 2 FRX, will 1 FRX be suffice to do the same, so that based on that parameter report is controlled.
 
The choice New line/New Page is a property of the group band, not evaluating any variable, expression or option, so you'd need to hack into the FRX data to change this before each REPORT FORM run. And this option will be effective for the whole report and all groups. It's not unusual to do such "hacks" and copy a FRX/FRT template report file to USE and modify data and REPORT FORM the modified copy, that means excluding the FRX/FRT files from your EXE to be able to do so. You have to find what differs in the FRX with the new line vs new page setting and then do the same change via FRX data REPLACE or UPDATE.

Anyway, the other automatic decision you have in a report is obviously the third option, to start a group on a new page only when there is less than X inch/cm/mm space left on the current page.

Bye, Olaf.
 
One FRX should be enough.
But you should add one additional field in the cursor which is used for report.
Group by that field and set the group to start on new page.
Then when you need all groups to start on new page change values in that field.
When you do not need leave it blank.
That way you could start some groups on new page and other groups could be continuous.

Borislav Borissov
VFP9 SP2, SQL Server
 
Olaf, I knew hacking report could work. But in that case,whenever I update my report, I will have to copy it to every station.
Nice approach Borislav, Thanks. It will solve my problem.
 
Well, you don't have to copy changed reports to each station for every instance. You have a template report wher oyur DBFs are and your app gets that and modifies it, like it normally gets data. It's just a small DBF anyway, unless your reports are very complex.

I see how Borislavs idea coudl work, but then you'd need extra care about the nested grouping of groups for next page vs same page continuation. I think the "when there is insufficient space" option is very nice, it'll hinder a single group record or such nonsense to appear and still not waste paper in case two or more groups easily fit one page.

Such special demands always sooner or later led me into Word Automation, not even considering PDF output or Word output via foxypreviewer or FRX2ANY, simlpy don't doing VFP reports but Word automation. Lots of possibilities to control content of every page with word tables and other objects.

Bye, Olaf.
 
Word Automation might prove a good option but I don't have much knowledge about it. Also in VFP Output differs for different printers for the same report, that is big problem for me as in some printer my reports get cut from side and I have to instruct my users to use specific printer in which I have designed report.
 
No, you uncheck "save printer environment" and get a report universally running on a wide variety of printers. Obviously make sure the correct paper size is in the trays.
If you design for a printer you do an essential thing wrong, you design for a certain paper format (letter/standard/A4), but please not for a certain printer.

Bye, Olaf.
 
Yes, that's right.1 thing I observed was that even after selecting and designing report on A3 paper size, PDF24 or AdobePdf printers were printing full report on A4 size paper without cutting from sides whereas other printers not. For reports where I have many columns to print, I designed report on A3 size paper and print it on A4 size paper using PDF24, it got printed but same report cut from the sides on other printers. Any reason for such behaviour.

Also which is better option - Printable Area or Whole Area for page layout ?
 
PDF Printers don't really have a paper tray/feed, so this would need to be configured and will surely default to A4 or Letter. Designing a report for a paper size doesn't tell the printer to feed that size, no, that's not the way it works.

Since printable area is very printer specific, designing for that option means designing for the active printer. Not, what you want. Design for whole page and have large enough margins to print within a reasonable area. With many printers, especially inkjet, you may print almost 100% of a page, but it depends. Documents are better readable with margins anyway.

I know it can become very cumbersome to get a report working. For example it took me some time to understand Zebra printers will measure ribbin width as page width, even if the label roll is narrower. In that case still the best mode was to give the report a margin I wanted on label plus the distance to the ribbon edge.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top