This project is read-only.

SP2 Reporting

Topics: General, Attention VFPX Admins
Mar 10, 2008 at 3:37 PM
Edited Mar 10, 2008 at 5:13 PM
Bo,

First of all, Congratulations and thank you for taking this project ahead. Knowing your skills and commitment, I'm sure that you're the best person to take this important project. Good luck !

As you've already told us in your blog, you plan to deliver a new version of the Report*.app files soon with some workarounds for some of the existing bugs in the core. So, I'd like to suggest you another small "enhancement":

To add some variables, like :
_ReportExitPic
_ReportPrintPic
_ReportNextPic
_ReportPrevPic

and

_ReportExitToolTip
_ReportPrintToolTip
_ReportNextToolTip
_ReportPrevToolTip

That we could fill in our startup PRGs, in order to change the button pictures and tooltips from the report toolbars.

Currently, I work with my own APP files, with the pictures that I use in my environment, and the tooltips contain the translated tips in Portuguese. As you plan to be delivering new versions of the Report APPs, everytime that you ship a new version, I'll be obliged to update and recompile mine. So, I think that this could represent a big help for all other users as well, specially for those from non English speaking languages.

Kind regards

Cesar
Mar 10, 2008 at 5:08 PM
Hi Cesar.

Actually, I have another way to accomplish this. I've subclassed FRXHandlerForm, the parent class for all Report Builder dialogs, and made it generic, data-driven, and dynamically assembled so only one class is used for all dialogs. The table driving the assembly of a specific dialog at runtime specifies for each dialog how many pages it should have and the class for the container of controls to go on each page. The nice thing about making it data-driven is that you can subclass a container of controls (for example, PanelGroupExpr or PanelCalculate in FRXPanels.vcx) and then change the record in the table to use your subclass.

The benefit of this approach is that anyone can customize the Report Builder to meet their exact needs by simply creating a subclass of one of the Report Builder classes, or even creating their own new classes, and simply changing a record in a table without having to rebuild ReportBuilder.APP (unless the table is built into that application, of course). So, you don't have to worry about changes to ReportBuilder.APP done by the VFPX team or anyone else.

Bo, I'm willing to contribute this to the project if you're interested (I was already planning to do this but Cesar's message prompted me to mention this now).

Doug
Mar 10, 2008 at 5:56 PM
Hi Doug,

Thanks for your answer, and tips.
I've already used the technique of creating and "ExtensionHandler" class, using Emerson's technique, shown here:
http://weblogs.foxite.com/emersonreed/archive/2006/09/13/AsampleonhowtoaddfeaturestoReport_Listener.aspx

But the problem in this aproach is that we are obliged to use Report Listeners every time. If we create some simple variables that the APP can check, people will benefit without having to change their codes to use the listeners, and all the legacy codes will remain compatible.