FPW2.6 check if report available programmatically

I'm writing a program that uses a report. This program is usually compiled
into .exes, and when building, the project manager finds the report and
includes it in the .exe.

However, this program is sometimes called from a standalone prg I run in the
IDE. The report almost certainly won't be visible at run time and I don't
want to make an identical copy elsewhere (although that would work.) What I
would like to do is something like

IF isexe()
REPORT FORM report.frx TO PRINTER PROMPT
ELSE
REPORT FORM <full path to report>\report.frx ...
ENDIF

The best I've thought of is an ugly error trap:

m.lno_frx=.F.
ON ERROR m.lno_frx=.T.
REPORT FORM report.frx TO PRINTER PROMPT
ON ERROR
IF m.lno_frx
REPORT FORM <full path>....
ENDIF


Any other ideas?
--
TIA
Andrew Howell

Stephen
Thu Aug 18 05:41:31 CDT 2005

Forgive me if I have misunderstood your question, but I think you want to
detect if you are calling this from within an EXE or not.

If so you could use the VERSION() function.

IF "EXE" $ upper(version())
* running within the exe
ELSE
* running in the IDE
ENDIF

Stephen


"Andrew Howell" <ajh@work> wrote in message
news:eaSvTr8oFHA.3304@tk2msftngp13.phx.gbl...
> I'm writing a program that uses a report. This program is usually compiled
> into .exes, and when building, the project manager finds the report and
> includes it in the .exe.
>
> However, this program is sometimes called from a standalone prg I run in
> the IDE. The report almost certainly won't be visible at run time and I
> don't want to make an identical copy elsewhere (although that would work.)
> What I would like to do is something like
>
> IF isexe()
> REPORT FORM report.frx TO PRINTER PROMPT
> ELSE
> REPORT FORM <full path to report>\report.frx ...
> ENDIF
>
> The best I've thought of is an ugly error trap:
>
> m.lno_frx=.F.
> ON ERROR m.lno_frx=.T.
> REPORT FORM report.frx TO PRINTER PROMPT
> ON ERROR
> IF m.lno_frx
> REPORT FORM <full path>....
> ENDIF
>
>
> Any other ideas?
> --
> TIA
> Andrew Howell
>

Andrew
Thu Aug 18 06:26:51 CDT 2005

"Stephen Ibbs" <stephen@datadevelopments.co.uk> wrote in message
news:de1okr$8pv$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
> Forgive me if I have misunderstood your question, but I think you want to
> detect if you are calling this from within an EXE or not.

Ish.
That may work.
I'll try to explain the scenario:

We have a series of programs that we've evolved to run to produce our month
end reports. I am currently reviewing the whole procedure. Many programs
require an input date range and output filename setting, then running. It
takes quite a bit of time doing this to everything and is a bit of a pain to
run.

I decided to write a program sequencer which lets a user set global
variables (eg input date range, output directory etc.) and then runs
everything in the sequence. That bit works OK. I'm now going through all the
separate programs, making them work from the sequencer, tidying them up and
making their variables PRIVATE etc.

Whilst doing this I thought it would be really nice to allow the programs to
run on their own as before. I handled variables by checking if the global
parameter was defined. If not, it uses the local at the top of the program,
else it uses the defined global one.

That only leaves a couple of problems with running standalone; how to handle
functions and reports which the program uses which can't be found. An
example is an error report I have. Currently there is only one copy in my
company's source directory. This report is used by a routine common to
several applications (in which case project manager finds it and builds it
into the application) but I also want to use the routine in a standalone
program. I don't want to create carbon copies of the report of possible.


In writing all that I think I've realised what I need to do. :-)
In the front of my month end programs I just need a SET PATH TO <sourcedir>,
then the reports and functions will be found.

--
Thanks!
Andrew Howell

Stephen
Thu Aug 18 06:32:00 CDT 2005

Hope you solve the problem OK

Sincerely

Stephen

"Andrew Howell" <ajh@work> wrote in message
news:%239819e%23oFHA.2580@TK2MSFTNGP09.phx.gbl...
> "Stephen Ibbs" <stephen@datadevelopments.co.uk> wrote in message
> news:de1okr$8pv$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
>> Forgive me if I have misunderstood your question, but I think you want to
>> detect if you are calling this from within an EXE or not.
>
> Ish.
> That may work.
> I'll try to explain the scenario:
>
> We have a series of programs that we've evolved to run to produce our
> month end reports. I am currently reviewing the whole procedure. Many
> programs require an input date range and output filename setting, then
> running. It takes quite a bit of time doing this to everything and is a
> bit of a pain to run.
>
> I decided to write a program sequencer which lets a user set global
> variables (eg input date range, output directory etc.) and then runs
> everything in the sequence. That bit works OK. I'm now going through all
> the separate programs, making them work from the sequencer, tidying them
> up and making their variables PRIVATE etc.
>
> Whilst doing this I thought it would be really nice to allow the programs
> to run on their own as before. I handled variables by checking if the
> global parameter was defined. If not, it uses the local at the top of the
> program, else it uses the defined global one.
>
> That only leaves a couple of problems with running standalone; how to
> handle functions and reports which the program uses which can't be found.
> An example is an error report I have. Currently there is only one copy in
> my company's source directory. This report is used by a routine common to
> several applications (in which case project manager finds it and builds it
> into the application) but I also want to use the routine in a standalone
> program. I don't want to create carbon copies of the report of possible.
>
>
> In writing all that I think I've realised what I need to do. :-)
> In the front of my month end programs I just need a SET PATH TO
> <sourcedir>, then the reports and functions will be found.
>
> --
> Thanks!
> Andrew Howell
>

Andrew
Thu Aug 18 07:40:49 CDT 2005

"Stephen Ibbs" <stephen@datadevelopments.co.uk> wrote in message
news:de1rjg$bie$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
> Hope you solve the problem OK
>

After all that.....
I find that a hardcoded report path seems to be ignored in an application
built with a file of the same name!

So I can put this in a program:

REPORT FORM c:\this\does\not\exist\report.frx

and when the program is built to an application, project manager just looks
for "report.frx" in the usual search path and when the application is run, I
guess it looks in the application itself for "report.frx" first before
falling back to the hardcoded path.

Still, I prefer one SET PATH at the beginning to several hardcoded paths
scattered throughout and it is also necessary to fix function calls because
I can't do

m.result=c:\some\dir\func(par1, par2)

but I can do

SET PATH TO c:\some\dir
m.result=func(par1, par2)

--
Regards
Andrew Howell