Refer to Report in an EXE

[JackTheC]

To clarify my question I'll give an easy example:

I made a small MYPRG.PRG that takes a report name as parameter to do some stuff with that report:

parameter repname
create table dummy (name c(10))
insert into dummy values ('Jack')
insert into dummy values ('Jill')
report form (repname) to printer prompt noconsole  && this is the problem line
use

I compiled this PRG (together with many others) into an EXE called MYLIB.EXE
MYLIB.EXE is like a library file with many shared routines.

Then I create a project called MYMAIN which makes use of the shared library.
That project has 1 PRG and 1 Report in it. (Just for the example, friends)
The Program is called MAIN and the Report is called DUMMYREP.

set procedure to f:\bb\mylib.exe
do myprg with 'dummyrep'

This works fine as long as I am in the development environment or as long as the Compiled MYMAIN.EXE is in the same folder as where DUMMYREP.FRX and DUMMYREP.FRT are.
But when I copy the MYMAIN.EXE to another (empty) folder and run it, it tries to execute the REPORT FORM line, but it generates an error: file does not exist. It cannot find the DUMMYREP report or report files that I passed as a parameter. I agree it is not in de MYLIB.EXE but it is present in the MYMAIN.EXE. If all the files are in the same EXE there is no problem of course, but that is not what I want.

So the question is: How can I make use of a shared library or procedure.exe with reference to a report in the calling EXE?

 

[Olaf Doschke]

Try to compile mylib mylib as APP file only, don't build an EXE.
I'd say it shouldn't make a difference, because doing myprg in mylib.exe will NOT start a new mylib process, it uses that exe as "library" only, but you may also need to be more explicit about the usage of a prg in that separate exe than via SET PROCEDURE, you can

DO myprg IN mylib.exe WITH 'dummyrep'

or

DO myprg IN mylib.app WITH 'dummyrep'

Bye, Olaf.

 

[JackTheC]

Thanks Olaf for the very fast response.
I found no difference in APP or EXE. Both did not work.
Both your examples did not work either. It says mylib.exe or mylib.app does not exist.

I tried these lines after Set procedure to f:\bb\mylib.app:

do myprg with 'dummyrep'
do myprg in mylib with 'dummyrep'
do myprg in mylib.app with 'dummyrep'
do myprg in f:\bb\mylib.app with 'dummyrep'

Line 1: Runs the myprg but: File does not exist, this was the original question
Line 2: mylib.prg does not exist
Line 3: mylib.app does not exist
Line 4: Runs the myprg but: File does not exist, like in the original question

Again, Line 1 and 4 do work when the actual report files *.FRX and *.FRT are present in the folder not just in the MAIN.EXE.
But of course I do not want source files in a runtime environment.

 

[Mike Lewis]

Jack,

Just to be sure, are you sure that Dummyrep.FRX has not been excluded from the build? You've probably already checked that, but if not, it would explain the error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JackTheC]

Hi Mike,

Yes, the dummyrep is included in the Mymain.exe, the exe that calls the shared library.
When myprg is incorperated in the Mymain.exe line 1 does work, of course.
But only if I remove the Set Procedure line. The myprg in the library seems to take priority above the one in Mymain.exe.

But as stated, I want my building blocks or wrapper routines in the shared mylib.exe.
I work with a shared library.exe in VFP for 20 years now. But I never used a shared wrapper routine for a report that lives in the calling program.
This seems impossible at this moment.

 

[Olaf Doschke]

I don't know what exactly happens here, but I neither get the REPORT FORM in the APP to find the report in the EXE nor in the APP.

For now it looks like you have to split up modularized code, you can do the report preparation in an app or external exe, but not the REPORT FORM call. If that's all the problem, I would say it wouldn't be too bad you'd need the extra line of report form and call:

set procedure to f:\bb\mylib.app
do myprg && calling myprg.fxp within mylib.app
report form dummyrep to printer prompt noconsole

That works, the app can prepare the dummy.dbf for the dummyrep.frx

In the end, I prefer to exclude reports. Excluded frxes are also available to another app or exe, so that would mean you'd be able to run the REPORT FROM within the app library module.

The "finding files inside exe" behavior is including reports, as we know from running a report merely by its stem name (without path and frx file extension), if it's all in one EXE. So there seems to be a difference how this works when the report form is not in the EXE the report is in.

Bye, Olaf.

 

[AndrewMozley]

Not sure whether this is completely relevant, Jack, but this is my experience.

I have an application where several of the report layouts may be modified; in this case the .frx report layouts are available on the PATH at run-time.

If the report name is not explicitly referred to in a MODIFY REPORT or REPORT FORM instruction, that works fine.

So if the relevant instructions are something like (1) :

LOCAL lRepname
lRepName = “Myreport”
MODIFY REPORT &lRepName
REPORT FORM &lRepName TO PRINTER PROMPT NOCONSOLE

. . . the user is able to modify the report layout – for this and subsequent runs.

But if the instructions are something like (2) :

MODIFY REPORT MyReport
REPORT FORM MyReport TO PRINTER PROMPT NOCONSOLE

. . the report layout is bound into the project - You will see it included under Documents | Reports. This happens automatically after clicking on Build in the Project Manager

In this latter case the resultant exe file is bigger by perhaps 20K.

At run-time in case (2) – explicitly referencing the report name in the MODIFY REPORT - the report may appear to be being edited; but when the subsequent REPORT FORM command is executed, it just works from the version bound into the .exe file

So (in your case), if you include a line REPORT FORM MyReport in the calling program (even if you don't actually execute that instruction), I believe that may bind Myreport.frx into your .exe file. Otherwise you will need to have Myreport.frx available in the PATH at run-time.

Hope this helps. Andrew

 

[Olaf Doschke]

Andrew, while all this is true, ou don't need to write alternative code to prevent this. Just a) keep the reports in the project manager, but b) right click and "exclude" it, and it's not put into the EXE.

Jack wants to have it included, maybe so users can't change it, our needs vary, but indeed excluding it and having it as separate files extends the possibilities.

Bye, Olaf.

 

[JackTheC]

Indeed, I don't want users to be able to modify reports or even see FRX and FRT files.
And the actual routine to be shared is much more complicated than the example shown. It has around 200 lines of code with API calls etc. Some code before the REPORT FORM command but most after it. I want to call the routine with one simple instruction like in the example. With 1,2 or 3 parameters.

I've been experimenting a bit:
In main.exe I do USE DUMMYREP.FRX (is in the exe) this works because a report is actually a normal DBF with a renamed extension.
and although this table is in a read-only exe it can be opened.
In the shared myprg I start with BROWSE, and this works. So the report table can be made available in the external shared routine.
But when I close the table and USE DUMMYREP.FRX again, it gives the error that the file does not exist.
This is all consistent with the problem discussed.

But this gives me the opportunity to copy the dummyrep.frx, while still open, to a place outside the exes, and do the REPORT FORM on that copy. Afterwards I can erase the copy.
I am not happy with this workaround because it takes at least two or three lines of code to call the routine and I don't like copying temporary files, but for now I have to live with it.

Thank you all.

If you wonder what is in the shared routine: I was tired of the default documentname of the printed output as it appears in the printer spooler or in a PDF Title or OXPS file etc. It was "Visual Foxpro" till version 7 and the path+report name afterwards.
One couldn't change that in normal VFP AFAIK. The routine gives the opportunity to the developer to give it any name at runtime. And without the path.

 

[Olaf Doschke]

In regard of control about the output file name, that only plays a role for outputs as file, doesn't it? PDF? PDF Creator offers options to name the documents.

In regard of saving lines in the call, I already gave you the idea to copy out report files at startup, just one place where you do this once and then both the main EXE and modules can refer to these outside files. You do this at each startup and overwrite files with SET SAFETY OFF, any modifications made therefore will be reset, any wear and corruption of external files is repaired etc.

Bye, Olaf.