Browse DevX
Sign up for e-mail newsletters from DevX


The Visual FoxPro 9 Report Writer

Microsoft has significantly improved the Report Writer in Visual FoxPro 9, while maintaining compatibility with previous versions of Visual FoxPro Reports, making the new Report Writer a great blend of the old and the new.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

n this article, you'll learn about the new reusable data environments, report protection, and several user interface enhancements, enhancements to layout objects and data groups. Finally, you'll learn about one of the best improvements to the Visual FoxPro 9 Report Writer: multiple detail bands.

The Report Designer: By default, the new Visual FoxPro 9 Report Writer uses the new Xbase Report Designer. It provides newer dialog boxes and is easier to use than the old version. It also provides access to many of the new features that are not available through the old Report Designer. You can easily control which Report Designer is used by changing the value of the new _REPORTBUILDER system variable.

*-- Use the new Report Builder _REPORTBUILDER = HOME() + 'ReportBuilder.app' *-- Use the old Report Builder _REPORTBUILDER = ''

The Output Engine: Just as with the Report Designer, you can control whether the new or old output engine is used. Unlike the Report Designer, which defaults to the new style out of the box, Visual FoxPro 9 defaults to the older output engine. The reason for this is that GDI+ is used in the new engine, and renders slightly differently than the GDI used by the old engine. Therefore, some of your existing reports could render differently in Visual FoxPro 9, which means you'd have to tweak them to make them appear correctly. You can switch between the output engines with the following command:

*-- Use the new output engine SET REPORTBEHAVIOR 90 *-- Use the old output engine SET REPORTBEHAVIOR 80

The rest of this article assumes that the new Report Designer and the new output engine are both in use.

Data Environments
The Visual FoxPro 9 Report Writer can now share Data Environments with other reports. Data Environments can also be saved as a class and then loaded into reports as needed. This offers a great reuse scenario for defining common reporting needs.

To save a Data Environment as a class, start by defining the Data Environment in a report as usual. While the Data Environment window is still active, select the new "Save As Class..." option from the File menu.

After selecting the "Save As Class..." option, the Save As Class dialog box appears (see Figure 1). The DataEnvironment button of the Save option group is the only option button-enabled when saving a Data Environment for a report.

Figure 1. Saving Data Environments: Use the "Save As Class" dialog box to declare the name of the new class and the class library for saving the Data Environment of a report.
Enter a name for the class in the "Name" textbox. Next, enter the name of the class library you want the new class saved in. If you enter the name of a class library that does not exist, the new class library is created for you. You can also use the ellipse button to brows for the location of an existing class library. Finally, you may optionally enter a description of the new class.

Loading a Data Environment
In addition to manually defining the Data Environment for a new report, Visual FoxPro 9 also gives you the option to load the Data Environment from an existing report or from a saved DataEnvironment class. The "Load Data Environment..." option on the Report menu allows you to select which Data Environment to load.

Loading a DE from a Report
When loading the Data Environment from another report, all the code and members of the original Data Environment are copied into the new report. This means any changes made to the original report's Data Environment after the fact are not propagated into reports created from the original report.

The Report Properties dialog box shown in Figure 2 appears after selecting "Load Data Environment..." from the Report menu. Use this menu to select the report from which you wish to copy the Data Environment.

Figure 2.: Report Properties Dialog: Use the Data Environment tab of the Report Properties dialog box to choose which report you want to copy a Data Environment from.
Select the "Copy from another report file" option button and then click the "Select..." button. This invokes the Open dialog box so you can choose which report to copy from. Once you chose a report, a confirmation dialog box appears.

Visual FoxPro 9 is about to copy the Data Environment from another report to the current report. Visual FoxPro 9 notifies you that it's about to overwrite the current Data Environment, and you must click Yes to continue. This helps remind you that anything you have defined in the Data Environment of the current report is about to be overwritten. If you click No, changes are not made and the process is aborted. When you click Yes, the Data Environment is copied and you are notified by another dialog box.

You are now finished copying the Data Environment. You may manipulate the Data Environment as needed. However, remember that any changes made to the original report's Data Environment after this point are not propagated to this new report.

Loading a DE from a Class
When loading the Data Environment from a class, code is added to the Data Environment of the new report to bind to the original DataEnvironment class and instantiate it at runtime. This means that future changes made to the DataEnvironment class will propagate into any reports using the DataEnvironment class.

Using the Report Properties dialog box shown in Figure 2, click the "Link to a visual DE class" button. Next, click the "Select..." button to invoke the Open dialog box that you can use to choose which class library and which class to use. After confirming your intentions, the Data Environment is updated and you are notified of its completion.

At this point, code has been added to five Data Environment methods: Init(), BeforeOpenTables(), AfterCloseTables(), Destroy(), and Error(). Some of the methods have very simple code with nothing more than a DODEFAULT() command. The reason for this is that BindEvents() does not function unless the method contains at least one line of code. Look at the code in these methods to see what it does, but I do not recommend that you change it.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date