Bypass included (in exe) report and to use report from disk with same filename

[Rajesh Karunakaran]

Dear Team!

Happy to be here! I just joined and this is my first post in this forum.

I have included a report in my executable. But for one client, I have to run
slightly modified report. So, I made a copy of the FRX and copied it into
a sub-folder in his application folder (similar to the folder structure I use
in my project file). Too, please note that the filename in his folder is same
as that in the executable.

However, how can I instruct vfp to bypass the report file in the executable
and to use/run the one from the disk instead?

Is this impossible or is there a way?

Thanks in advance
Rajesh Karunakaran
Mauritius.

 

[Olaf Doschke]

I would need to try whether REPORT FORM c:\...\yourapp\reports\thereport.frx - a REPORT FORM call with the full path to the frx file - would use that external report rather than a report named thereport.frx included in the EXE. But I fear it won't. What I know is, that the EXTERNAL command is of no help here, because it only calms down the project manager and BUILD command about undefined references, it doesn't help for defined references, your only chance is a concrete absolute path to the report file is making VFP look there first, but I don't think so. The preference for internal files was done to protect against outside overrides.

I just tried a REPORT FORM absolutepathoFRX and no, the internal FRX with same stem name is called, no matter if the internal report was already run (and the file memorized) or not.

Anyway, since you can't have a setting making an already existing EXE look for external files first, you need to change code and recompile anyway, so you could give reports another name, first check for existence of external files at expected locations and then use them instead of internal files.

Like this:

Local lcBaseDir
lcBaseDir = Addbs(JustPath(Sys(16,0)))+"extern\"

Local lcReport
lcReport = "thereport"

If ADir(laDummy,lcBaseDir+lcReport+"external.frx")=1
   lcReport = lcBaseDir+lcReport+"external.frx"
EndIf
Report Form (lcReport) Preview

This means the internal report is named thereport.frx and the external one thereportexternal.frx. If it exists it will be used, if not the internal one.

Bye, Olaf.

 

[Mike Lewis]

Hi Rajesh, and welcome to the forum.

I'm thinking on the same lines as Olaf. I can't see any way of adding this functionality retrospectively (that is, after you have built and distributed the application). But you can provide it as a useful feature into the application, which can then be used by as many or few users as you like.

You first need to establish a dedicated directory to hold the custom reports. Then, when you create a custom report, give it the same name as the built-in report, but with a special suffix, such as -x. So if Sales.frx is the built-in version, the custom report will be Sales-x.frx. Place that file in the dedicated directory.

When the time comes for your program to run the report, it should first check to see if the dedicated directory exists, and, if so, if it contains the -x form of the report. You can use ADIR() or FILE() for that. If it does exist, run that report, specifying the full path name in your REPORT FORM command. If it doesn't exist, just run the built-in report as usual.

Where I differ with Olaf (slightly) is that I would not put the custom report into a sub-directory below the base directory, but rather in a sub-directory off one of the special user folders, such as User Data or My Documents. But that's a personal preference, and not the main issue. (If you don't know how to locate those special folders on the user's system, see

http://www.hexcentral.com/articles/foxpro-folders.htm.)

I hope this helps.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The different folder, eg under appdata, is a good idea, since the app folder also typically is readonly and can only be written to at setup time. But you can also create a folder users are able to write to, even with the limited installshield express.

Anyway, what I'd now rethink is having a suffix for external reports. Perhaps rather have one for internal reports, so the names of external reports don't look weird. On the other hand, when you start making this a general feature by always going through such a external-if-exists switch code and you still would like your customers to need customizations even after they know that mechanism, the file names should perhaps have a dynamic suffix. It obviously can't depend on current time or location, it also shouldn't be a configurable single value, it could be a CRC or other (partial) checksum or hash value of the internal file name, anything you can compute but what wouldn't reveal itself even after giving a customer a first external customization.

In the end they normally won't have Foxpro at hand to edit external reports anyway, but allowing such changes from outside to be made invites people trying to get around needing your assistance.

Bye, Olaf.

 

[GriffMG]

I do this for most reports - I use a suffix 'Alt' and test for the presence of the .frx in the data folder.

This enables me to provide (rarely these days) custom reports for each project the client is running, so logos and layouts can easily be changed.

Thus ten client PCs can run the AltReport.frx for project A without having to install the AltReport.frx on each PC.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[JRB-Bldr]

to use report from disk with same filename

But for one client, I have to run slightly modified report

Since you 'point' VFP to whichever Report Form you want to use at any point in time, you might want to consider changing the individual Report Form filenames - for maintenance reasons.

If they are both named the same, then it is very easy to get confused as to which one is which.
If modifications need to be done to one of them, with the same name for both, can you be certain that you made them to the correct one?

Instead you might consider something like:
StandardRpt.frx && 'normal' report form name
ClientNameRpt.frx && custom client report form name

Then when you need to run them (as Olaf has advised above)....

SELECT RptData
IF ClientName = "SpecialCustomer"
   * --- 'Special' Customer ---
   cReportForm = ADDBS(<external drive + directory>) + "SpecialCustomerRpt.frx"
ELSE
   * --- 'Standard' Customers ---
   cReportForm = "StandardRpt.frx"
ENDIF
REPORT FORM (cReportForm) TO PRINT

Good Luck,
JRB-Bldr

 

[Rajesh Karunakaran]

Dear Mike, Olaf, Griff & JRB,

I am overwhelmed!
I know about the forum, but when I receive answers to my own question in this much detailing, that too within no time, it is special!
Thanks a lot dear experts! You guys are great!

I put up this after trying different scenarios to check if foxpro takes the external report file if I explicitly give a path reference (in the REPORT FORM ....). But, it didn't! So, I also was thinking exactly the same way that all of you have suggested, ie to use a different name for customized reports. Yes, it is the standard report form filename with '_ext' added at end.

Just to let you know what I do (sorry if I am unnecessary elaborating)
In my app, I have specification for report format names for a few documents (say invoice, receipts etc) which can be set through an admin module. So, while printing, I check, if there is a specification mentioned for a document format or not. If yes, I run that (obviously if that format file exists!) or it runs the INCLUDED format (the default or standard as we shall call it).

Too, if I have a customization for a client, I keep that file in my development system in a separate folder for that client (yes, with a standard folder naming policy!) for further customization, if any.

Thanks a lot once again!
Rajesh Karunakaran

 

[Mike Lewis]

I'm glad we were able to help, Rajesh. And thank you for reporting back, to let us know what action you took. This is very helpful. Too often, people come to the forum and ask a question, then don't even bother even to acknowledge the replies.

Be sure to come back next time you have a VFP problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads