Modifying a report layout at run-time

[AndrewMozley]

I have an application which uses the MODIFY REPORT command so that the user can make changes to items such as labels so that he can tailor the report to his own requirements.

On my Win7 machine this works fine, both when run within a VFP session and when I run the application as a free-standing .exe.

On my Win10 machine, this works fine under VFP, but the full properties window was not being displayed unless I include ReportBuilder.app in the folder with my .exe program (I also see that I have to include several .dll files - vfp9r.dll, , vfp8renu.dll, msvcr71.dll, gdiplus.dll - in order for the .exe to run).

The report format is in a separate .frx file which I distribute with the application.

Is this the correct approach to follow, or is there another way of doing this (even binding some of this code into the .exe file)? Grateful for guidance - or being pointed in the direction of some relevant documentation - as ever.

 

[Olaf Doschke]

It's totally normal you need the ReportBuilder.app for reportengine 90, but not otherwise. You also need the two other apps then, especially for printing itself you need ReportOutput.app in that report mode, you otherwise revert to the reportengine beahviour in the vfp9r.dll runtime, and yes, those are of course needed, VFP has no linker whatsoever, an EXE simply is an archive of foxpro object code and needs a runtime including C++ runtime to really run, it's not self contained, but that's also quite normal, .NET assemblies and executables need a .NET framework, VB executables need a VB runtime, C executables and DLLs also need a C/C+++ runtime. Native code only is assembler, but nobody does assembler these days.

Your report never is an SCX, it is an FRX/FRT file pair.

Bye, Olaf.

 

[Mike Lewis]

... so that the user can make changes to items such as labels

If your main requirement is to let the user change the text of the labels, then you might consider a completely different approach.

Instead of distributing the report builder, you could create your own form that lets the user enter and save their chosen text for the labels. The form would show the existing (built-in) text, which the user would then be able to edit. The form would then save the edits in a table.

When the time comes to print the report, you would access that table, and pass the users' chosen wording to the report in the form of variables (or the report could perhaps access the table directly).

Obviously, this is a much more limited approach. The user wouldn't be able to change the position of the fields, or modify any of the formatting. On the other hand, by limiting what the user could do, you would remove the risk of them completely mucking up the report. After all, the VFP report designer is not the most user-friendly of tools.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

To contrast Mikes recommndation against offering FRX modifications for end users:

There is a protected mode for report modifications, it requires quite tedious preparations on your side, though, in the normal design mode of the report you need to specify each and any control and detail you want to protect or allow for modifications in protected mode. It's unfortunately not that practical, as it depends on a very fine granular definition of what is protected, you can't just lock in all controlsources, for example.

From that perspective I can share Mikes point of view, but if it's important for you you might go through this work to enable and disable the editing of report features as you need it.

Bye, Olaf.

 

[Dan Freeman]

For a more complete list of files needed for a runtime application see

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles

 

[AndrewMozley]

Thank you all, particularly Dan. Managed to get through to your link which gave a table of run-time files which may be needed (although it is at present giving a message ‘File c:\wiki\wwsession.fpt is to large’ That may just be a temporary glitch). At present I am putting these six files into the folder from which users start the application :

Myapp.exe
vfp9r.dll, vfp8renu.dll, msvcr71.dll, gdiplus.dll
ReportBuilder.app

This folder is on the server, as are the data files which the application uses. That seems to work.

I take your point, Mike and Olaf, about perhaps controlling the range of report modifications allowed by the user. At present it is not a problem, since the number of sites running the application is small and fact it has usually been me, running the application on their installation, who has altered the text, included a Logo &c on the invoices, Purchase orders and the like.

 

[JRB-Bldr]

so that the user can make changes to items such as labels so that he can tailor the report to his own requirements.

Personally I agree with Mike's suggestion.
There are too many ways in which users can totally mess up a Report Form to the point where it will no longer work. If they do that, sure it is their fault, but it would be your job to get them back working.

Since you are talking about only labels, these could very easily be supplied to the Report Form by variables.
And these variables could be acquired from a customer-specific record in a separate data table (example: ReportLabels.dbf) that is accesses before the REPORT FORM command is issued.

In that way, you could even have different customer-specific records for different reports all within the same customer's system.

Good Luck,
JRB-Bldr

 

[Tore Bleken]

The error you get, "wwsession.fpt is to large", isn't related to this problem at all. wwsession.fpt is one of the files uses by West-Wind Web Connection.

 

[Mike Lewis]

The error you get, "wwsession.fpt is to large", isn't related to this problem at all. wwsession.fpt is one of the files uses by West-Wind Web Connection.

I think Andrew was saying that he saw that error when he tried to access the Fox Wiki - not when he was trying to run his program. Presumably the Wiki is now exceeding its capacity. No doubt Steve (or whoever is running the site now) will see it and fix it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

You're right, sorry for the mistake.