Does REPORT activate the main screen ?

[MossNelson]

My application (a VFP8 exe) contains a report which runs inside of a SCAN/ENDSCAN loop. The loop will execute approximately 3000 times and with each pass output a single REPORT FORM TO PRINTER NOCON command to various printers.

The problem: I would like my users to be able to do other things during the 4 hours or so that this report runs.
If I minimize the application screen and switch to some other open app on the desktop - the VFP app brings itself to the top again.

A little debugging and I discovered that this happens as I issue the REPORT FORM command. So the app is minimized for 5 seconds or so and then boom - it's on top again. Needless to say this is unacceptable because now no other work can be done at this workstation.

Does anyone know if this behavior can be changed or is it simply a function of the REPORT command that it must bring itself to be the foreground application to do it's thing ?

 

[rgbean]

What's the actual REPORT copmmand statement? Does it include PREVIEW, PROMPT, IN WINDOW or some other optional clause?

Rick

 

[MossNelson]

Rick,

This is the command I am using:

REPORT FORM lcdtl.frx TO PRINT NOCON NODIALOG

 

[jimstarr]

Have you tried minimizing the application screen programmatically right before the REPORT command?

Jim

 

[Mike Lewis]

Nmoss,

How about if you execute _SCREEN.Visible = .F. immediately before you start printing, and _SCREEN.visible = .T. immediately after?

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[MossNelson]

>>> minimizing the application screen programmatically <<<

Yes, Jim, I tried this and it works for a few seconds until the loop reaches the REPORT then the screen comes to the foregound again.

Mike,
>>> execute _SCREEN.Visible = .F. <<<

I will try this but it would be unnerving to not see the screen on a report running for 4 hours or more. The user may need to see the progress bar on my form to see the percent completed.

 

[Mike Gagnon]

A little debugging and I discovered that this happens as I issue the REPORT FORM command. So the app is minimized for 5 seconds or so and then boom - it's on top again. Needless to say this is unacceptable because now no other work can be done at this workstation.[/code]

Create a separate executable the will run your report, with no interface. When it is compiled, it shouldn't pop up every time it prints out.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[MossNelson]

>>> Create a separate executable the will run your report <<<

I am not sure exactly what that would accomplish? I would have a standalone executable that is grabbing the foreground and still would not be able to do anything else on the workstation which is running my report.

Although I appreciate the various suggestions, it is puzzling to me that no one else is as alarmed about this as I am.

A Windows application that hogs the desktop foreground even after it is explicitly told to go to the background is exhibiting very bad behavior indeed.

 

[jimstarr]

I'd try minimizing the screen programmatically within the report itself, in the BeforeOpenTables method of the data environment.

Jim

 

[jimstarr]

... or maybe the INIT would be better. -Jim

 

[Mike Gagnon]

I am not sure exactly what that would accomplish? I would have a standalone executable that is grabbing the foreground and still would not be able to do anything else on the workstation which is running my report.[/code]

Maybe I didn't explain properly. If you create a COM server application, no interface (Meaning if you click on it it does not open any interfaces) and run it as a service (in your scheduled tasks for example), this application will only appear in the Windows Task manager and never grab the foreground.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.