Report with NOCONSOLE and REPORTBEHAVIOR 90 2

[MossNelson]

Hi, I would like to upgrade my VFP reports with some of the features available with Set Reportbehavior 90 in VFP9 SP2.

If I call a report using the standard REPORT FORM myreport.frx TO PRINTER NOCONSOLE with Set Reportbehavior 90 I get "TALK" back to the calling form. Eventually, it overruns the calling form with messages and happens even though SET TALK is Off.

Interestingly enough, it does not happen on a development machine only when run inside an exe. Set Reportbehavior 80 stops it from happening. Any idea why the NOCON is being ignored ?

 

[Mike Lewis]

We discussed this problem a couple of months ago. See this thread: thread184-1640637, and particularly the post by Doug Hennig, which refers to this article:

http://cathypountney.blogspot.com/2009/04/set-talk-appears-to-be-on-when-running.html

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[MossNelson]

Mike,

Thanks for pointing me in this direction. I actually did an initial forum search on NOCONSOLE and did not find it.

First I tried this solution and it did not work for me.

>>> Modify the fxListener class of the _ReportListener class library and change the code in the LoadReport method. Simply move This.setFRXDataSessionEnvironment() so it comes before This.createHelperObjects() and the problem is solved. <<<

Then I did "SET CONSOLE OFF" just before calling my report and it works. However I was wondering what other consequences there may be to leaving SET CONSOLE off or should I reset it after the report completes?

 

[Dan Freeman]

Well, if Cathy's instructions didn't work for you we probably ought to figure out *why* rather than throwing out the baby with the bathwater. The instructions are sound and the fix is good.

If your application relies on the ? command to print information to the currently active window, you'll want SET CONSOLE ON at that time. Of course, relying on printing to the current window with ? is a VERY OLD way to do things.

If your application relies on VFP's "native" information for things like the INDEX command displaying to the user, then you'll need SET TALK ON.

The two commands are sort of separate and sort of independent but sometimes intertwined as well.

I'd really recommend figuring out why Cathy's fix didn't work for you before you try engineering your own.

 

[Mike Lewis]

NMoss,

I noticed that one of the people who posted a comment to Cathy's article also found that they had to issue SET CONSOLE OFF to make it work.

In general, there is no harm in setting CONSOLE off while a report is running. Normally, you would use the NOCONSOLE keyword with your REPORT FORM command, but if you find that you need to explicitly issue SET CONSOLE OFF, that's fine.

In fact, there is usually no reason to allow console output at all during the execution of an application - unless you are using the "?" command, which is not recommended.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Mike,

It makes me a little uneasy to use SET CONSOLE to suppress the output of SET TALK. It's like using a garden rake to water the plants -- wrong tool for the job.

If people are doing that, however, I just noticed something in the help file that could explain at least one of the recent posts we've seen where output from SET TALK is appearing after an error:

An error always sets SET CONSOLE to ON.

Interesting, eh? This means that anyone considering always having it set to OFF may get surprises after an error.

 

[Mike Lewis]

Dan,

Hmm. A valid point, perhaps. I'm not sure whether or not I agree.

Keep in mind that I was only suggesting keeping the setting OFF in an executable, not in the development environment (actually, I don't think you can set it off in development).

Regarding the fact that an error always sets it ON, I can sort of see the logic of that. But I take your point about it being a surprise, especially if it's an error that doesn't close the program (like "No printer installed").

Perhaps the best advice we can give to Nmoss is to save the setting of CONSOLE immediately before the REPORT FORM command, and then restore it afterwards.

Regarding the tool used to water the plants: there's something that's outside my experience. Where I live, people don't explicitly water their plants. It just somehow happens.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Hi Dan,

that's a very nice finding in the help file and explains a lot in regard to the referenced thread184-1640637.

Thanks!

Bye, Olaf.