vfpreportwriter_newin8

8/8/2019 VFPReportWriter_NewIn8

http://slidepdf.com/reader/full/vfpreportwriternewin8 1/8

Appendix A: What’s New in the VFP 8.0 Report Writer 1

Appendix A

What’s New in theVFP 8.0 Report Writer Yes, hell has frozen over and pigs do fly!! Microsoft has made some improvements to theReport Writer in Visual FoxPro 8.0. Some developers thought this day would never come,but surprisingly it has.

Now before you get too excited, the Visual FoxPro team at Microsoft didn’t do any major rewrites to the Report Writer. They did, however, give us some much needed minor improvements. For example, we now have the ability to get rid of the printer-specific binarycodes without having to hack the FRX. We can also print “Page x of y” with ease. These changesaren’t major – but they sure do make our lives easier!!

In addition to giving us some new enhancements, the VFP Team has also fixed a few bugs,described later in the section titled, “Bug Fixes”.

Design-time enhancementsVisual FoxPro 8.0 has several enhancements to the Report Designer including a new checkbox toinclude or exclude the printer environment, the ability to drag and drop captions from the DBC,and a new Report tab on the Options dialog.

Printer Environment Visual FoxPro saves specific information about the printer you’re using when you design thereport in the report definition itself. This printer-specific information has the potential for causing

problems when a user runs a report and they don’t have the same printer you used to design thereport. In fact, under certain conditions the dreaded C0000005 error can occur – yikes!

For peace of mind, the best thing you can do is strip out any printer-specific informationfrom each report. Prior to Visual FoxPro 8.0, this wasn’t easy. In fact, you had to hack thereport’s FRX file to do it. Luckily for us, though, it’s very easy to do in VFP 8.0.

Select Report | Printer Environment from the main VFP Menu bar to toggle the Printer Environment setting. Checking this option tells Visual FoxPro to save the printer environmentinformation in the EXPR , TAG and TAG2 fields in the first record in the FRX file. Conversely,unchecking this box tells Visual FoxPro to not save any printer environment information in the

FRX file. I recommend unchecking this option on all your reports.

Drag & Drop DBC CaptionsVisual FoxPro allows you to drag and drop fields from the report’s Data Environment onto thereport definition. Prior to Visual FoxPro 8.0, the only thing that was dropped onto the report wasa report object for the field itself. Now, with Visual FoxPro 8.0, it’s possible to have the captionsdefined in the DBC dropped onto the report too. In the event there is no caption defined, the fieldname is dropped onto the report instead.



2 The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond

The ability to drag and drop field captions is toggled on or off by a setting on the Report tabof the Options dialog (see the following section titled, “Report tab on the Options dialog.”)

Report tab on the Options dialog A great design-time enhancement to Visual FoxPro 8.0 is the new Reports tab on the Optionsdialog (see Figure 1.) This page on the Options dialog has a number of options including severalgrid settings, several report options, the default report font and a few other miscellaneous settings.

Figure 1. Use the Reports tab of the Options dialog to change global Report settings.

Grid settingsYou may choose to toggle the Grid lines and Snap to grid settings of reports as well as thehorizontal and vertical spacing of the grid lines. Changing these settings only affect new reportsdefined in Visual FoxPro. Any preexisting reports maintain the settings last saved with eachreport. These settings are only defaults to be used when creating new reports.




Report optionsThere are three report options that can be set in the Options dialog. The first two settings, Use private data sessions and Save printer environment only affect new reports defined in VisualFoxPro. Any preexisting reports maintain the settings last saved with each report.

The third report option, Drag and drop field captions controls what happens from this pointforward. At the time you initiate drag and drop in the Report Designer, Visual FoxPro looks atthe setting in the Options dialog to determine whether to drop field captions along side each field.

Miscellaneous settingsThere are three miscellaneous report settings in the Options dialog. Similar to the Grid settings,these options determine the default used when creating new reports. Any preexisting reportsmaintain the settings last saved with each report. The three options are Show position, Ruler scaleand Default font. I don’t know about you, but I jumped and shouted when I learned about theDefault font setting – it’s a welcome enhancement!

Running ReportsVisual FoxPro 8.0 has some new enhancements for running reports including the ability tosuppress the “Printing…” dialog, the ability to chain multiple reports together, and a new systemvariable for determining if the user is printing or previewing. Visual FoxPro 8.0 has also made animprovement to allow errors in reports to be trapped just like any other error in Visual FoxPro.

Suppress the “Printing…” dialog The “Printing…” dialog box appears when you print to the printer. Many developers havewanted to suppress this dialog. Unfortunately, prior to Visual FoxPro 8.0, there was no way to

prevent this. The only option available was to fake it out, which makes it appear as if it doesn’texist even though it really does.Visual FoxPro 8.0 has introduced a new clause for the REPORT command that allows you to

suppress the “Printing…” dialog. Use the NODIALOG clause as follows:

REPORT FORM MyReport TO PRINTER PROMPT NODIALOG PREVIEW

Adding the NODIALOG clause tells the Visual FoxPro Report Writer to skip creating or displaying the “Printing…” dialog. Be sure to put the NODIALOG clause between the TOPRINTER PROMPT and the PREVIEW clause or an error occurs.

Is the user printing or previewing? Many times you need to know whether the user is previewing the report on the screen or printingthe report to the printer. For example, if the report is for invoices that are printed on pre-printedforms, you wouldn’t include the company name, address, logo, or graphical lines on the report.Yet, this makes it difficult to read when previewed on the screen. The solution is to include thecompany name, address, logo, and graphical lines on the report, but only print them when theuser is previewing.

Visual FoxPro 8.0 introduces the SYS(2040) function to help you determine the state of printing. A return value of 0 means no report is printing or previewing at this time. A return valueof 1 means the report is previewing and a return value of 2 means the report is printing. Note that




the return value is character, not numeric. Simply use SYS(2040) = ‘1’ in the Print Whenexpression of a report object if you only want the object displayed in preview mode. Use SYS(2040) = ‘2’ if you only want the object printed on the hard copy.

Chaining reportsI have a client who has one report that in reality consists of several different Visual FoxProreports. This client wants to choose one option from the menu, select the printer once, and havethe full report print.

But wait – there’s more! This client’s scenario gets a little trickier. Besides printing all threereports as one, they also want the page numbers to continue from one report to the next. For example, if each report consisted of three pages, report1 needs to show pages 1-3, report2 needsto show pages 4-6, and report3 needs to show pages 7-9 in the footer.

Visual FoxPro 8.0 has introduced a few new clauses to help you chain reports together. The NOPAGEEJECT clause tells the Report Writer to keep the print job open when the reportfinishes so another report can continue in the same print job. The NORESET clause tells the

Report Writer to not reset the page number when printing a report so this report’s page numbers pick up where the previous report’s page numbers left off.

To chain three separate reports together, use the following code:

* Print the first report* Use NOPAGEEJECT to keep the print job openREPORT FORM Report1 TO PRINTER PROMPT NOPAGEEJECT

* Print the second report* Don't use PROMPT* Use NOPAGEEJECT to keep the print job open* Use NORESET to keep the page numbers rollingREPORT FORM Report2 TO PRINTER NOPAGEEJECT NORESET

* Print the last report* Don't use PROMPT* Don't use NOPAGEEJECT* Use NORESET to keep the page numbers rollingREPORT FORM Report3 TO PRINTER NORESET

I have to admit that I’m not thrilled at how Microsoft implemented this new feature. First,you may have noticed that I didn’t include the PREVIEW clause in any of the commands. Thereason is that previews don’t get chained together. In other words, if the above example wouldhave included the PREVIEW clause, you would have seen three separate previews. Personally, Ithink this is extremely confusing to the user and will cause major support issues because the user won’t think to press the printer button for each different report that appears.

Another issue I have is the fact that you, the developer, has to remember to exclude the NOPAGEEJECT clause from the last report printed so the print job gets closed. This might befine when you are printing a known number of reports. However, when trying to chain reportstogether from inside a SCAN/ENDSCAN loop, you may not know when you are on the lastreport. This means when you get done with the scan loop, you still have an open print job that hasto be closed with a fudged report as follows:

REPORT FORM MyReport NEXT 0 TO PRINTER




I don’t consider this a very smooth way to handle the situation, but it’s about the only choiceyou have.

There are a handful of other issues that cause problems, such as combining landscape and portrait reports in one print job or using the new _PAGETOTAL system variable along with

chained reports (discussed later in the section titled, “Print ‘Page x of y’”.) But heck, at least thisis better than nothing!

Error handling in reportsPrior to Visual FoxPro 8.0, if an error occurred while running a report, nothing happened.

Nothing at all!! No FoxPro error was reported, no ON ERROR code executed, no report printed.Simply put, nothing happened.

With Visual FoxPro 8.0, this changes. Errors that occur in reports during runtime will nowtrigger the normal FoxPro error handling, including any ON ERROR code you have in place.The LINE() and PROGRAM() functions return the REPORT FORM command that initiated thereport. The ERROR() and MESSAGE() functions return information about the error that

occurred. Of course, you still have to track down which object in the report triggered the error.The best way to track down which report object triggered the error is to preview the report

from the Report Designer. Many developers don’t realize this, but when an error occurs while previewing a report from the Report Designer, you’re notified of the error, and then theoffending report object’s dialog is displayed. Then it’s up to you to investigate whether it’s theexpression, the Print When logic or something else. This is a huge time saver to have the ReportDesigner pinpoint the offending report object, instead of you having to go one-by-one througheach object looking for the problem.

In many cases, it’s hard to preview a report from the Report Designer because the reportrelies on cursors and tables and variables set up by the calling program. If you run into a reporterror in this situation, here’s how to overcome it. In the program that runs the report, change the

REPORT FORM command to the MODIFY REPORT command and then run your application. Now the application can prepare the data and variables as usual, but the Report Designer displaysinstead of the report trying to run. Once the Report Designer displays, just select Preview andviola! The error is displayed and the offending report object’s dialog appears.

New and Improved featuresA new much-asked-for feature is the ability to print “Page x of y” on a report. In addition to thisfeature, the VFP team has improved a few existing features. Stretching and floating of objects inthe Page Footer were not allowed in versions prior to VFP 8.0 and printing the Page Header andPage Footer in the Summary band was tricky to say the least.

Print “Page x of y” This has to be one of the most, if not the most, frequently asked questions by FoxPro developers.Prior to Visual FoxPro 8.0, the answer to this question wasn’t so easy. There wasn’t a systemvariable to hold the page count.

In Visual FoxPro 8.0 this has changed. Simply use the _PAGETOTAL system variable to print the page count in a Visual FoxPro report. Before processing a report, Visual FoxPro looksto see if the _PAGETOTAL variable is used anywhere. If it is, VFP does a two-pass process. Thefirst pass is done to get the total page count and the second pass is the final preview or print pass.




If the _PAGETOTAL variable is not used anywhere on the report, VFP does not do the two-pass processing so you don’t have to take the performance hit when it’s not necessary.

It’s important to remember that using this new system variable causes the report writer to doa two-pass process, especially if you are calling a UDF or method call that updates other data. To

avoid updating the data twice, wrap your code with an IF statement as follows:

IF _PAGETOTAL <> 0* Do your updating here

ENDIF

During the first pass, the _PAGETOTAL variable is zero. Therefore, it’s a safe assumptionthat if the variable is not zero, you are in the second pass which is when you want to update your data.

Previously, I mentioned that chaining reports with the new NOPAGEEJECT clause doesn’twork well with the new _PAGETOTAL variable. The problem is the first report doesn’t knowabout any reports that you are about to print. It only knows about itself and how many pages it

has. The second report knows about the first report and itself, but it doesn’t know about the thirdreport and so on. What this means is that you’ll get incorrect page counts on all but the last reportof the print job. For example, if you are printing three reports, each having two pages, the pagenumbering appears as follows:

Page 1 of 2Page 2 of 2Page 3 of 4Page 4 of 4Page 5 of 6 of 6

Stretch and float objects in the Page Footer Prior to Visual FoxPro 8.0, objects placed in the Page Footer band were not allowed to stretchwith overflow or float. Fortunately, this has been changed and you can now mark report objectsas stretch and float. This works great when you need to define footnotes that vary in length.Visual FoxPro figures out how much room is needed at the bottom of the page and stops thedetail band at the appropriate point.

There is one gotcha with this new feature. If you are calling a method or UDF in the Detail band to build a variable or memo field that you intend to print in the Page Footer, you could get bit. A common example of this is to build a variable that contains footnotes. For each record thathas a footnote associated with it, you can add the text to a character variable along with a carriagereturn / line feed (CHR(10) + CHR(13)). In the Page Footer, you can print the variable and have

the object stretch with overflow.Before printing a particular Detail band, the Report Writer checks to see if there is enoughroom left to print this Detail band and the Page Footer, taking into account any stretching objectsin the Page Footer. If it determines there is enough room for both, it processes the Detail band.Herein lays the problem. In your Detail band, you happen to call a UDF that adds additional linesto the variable you are about to print in the Page Footer. The Report Writer finishes up the Detail

band and moves on to the Page Footer. Only now there is too much information to print in thespace left on the page.

This is a real bummer because the above example is one of the main reasons we needstretchable fields in the Page Footer. However, in Microsoft’s defense, I can understand why this




happens and I realize that it’s a tough problem to solve. So for now, we just have to accept thislimitation.

Include the Page Header and Page Footer in the

Summary In versions prior to Visual FoxPro 8.0, the Page Header and the Page Footer bands did not printwhen the Summary band was set to print on its own page. Furthermore, there was a bug thatoccurred whenever the Summary band was not marked to start on a new page, yet it had to starton a new page for lack of room. Basically, the Page Header and the Page Footer band did not

print, causing the Summary band to look orphaned.In Visual FoxPro 8.0, there are two new check boxes added to the Title/Summary dialog to

help overcome these situations. The first checkbox, Page Header, tells Visual FoxPro whether thePage Header should print along with the Summary band. The Page Footer check box tells VisualFoxPro whether the Page Footer should print along with the Summary band.

The addition of the new check boxes still don’t correct thebug that occurs when a Summary band isn’t marked to start on its own page, yet overflows due to lack of room. Microsoft’sresponse to this bug is that you should check these new check boxes to solve the problem.Although this workaround solves the problem, I still stand by my statement that this behavior is a

bug.

Bug FixesSpeaking of bugs, the VFP team has corrected a few bugs in VFP 8.0. Notice I said, “few.” Many

bugs still exist in the Report Writer as documented throughout this book.

Edit Bands dialog A harmless bug in the Edit Bands dialog has been fixed. Each Group Header has a correspondingGroup Footer entry in the list box. However, prior to VFP 8.0, the Group Footer entries werenumbered incorrectly. Group Footer 2 actually corresponded to Group Header 1 and GroupFooter 3 actually corresponded to Group Header 2. Now you don’t have to strain your brain andsubtract one from the Group Footer number to find the one you are looking for.

No more ghostsI’m very glad to see the “ghosting” bug (see Figure 2) fixed in VFP 8.0. This strange appearanceonly occurred if you had a UDF or method call somewhere in the report. The first time youclicked on the report to zoom out, the VFP Report Writer only repainted the area that was

covered by the printable area of the page. In other words, the non-printable margins were notrepainted. Whatever information was on the screen in those areas, remained on the screen after the zoom.




Figure 2. The non-printable margins of the page didn’t get repainted under certaincircumstances.

As glad as I am to see this bug fixed, there is a penalty. Now when you zoom a report, itflickers two or three times. The report displays, then quickly disappears, and then displays again.

Oh well, nothing in life is free!

ConclusionIt’s nice to see the Visual FoxPro Report Writer finally get some attention. VFP 8.0 has given ussome new features, improved upon some old ones, and addressed a few bugs. Microsoft has alsoannounced that the next version of Visual FoxPro, codenamed Europa, will have many moreimprovements to the Report Writer. Let’s all keep our fingers crossed!!

vfpreportwriter_newin8

Documents