It's not "set talk" ???

[Beverly Howard]

Murphy is alive and well...

Thought I was going to be ready for a demo this morning and it seems
that I did something to turn on reporting similar to "set talk" but "set
talk" does not impact it.

What's happening is that the contents of all variables being populated
are being printed to the screen.

What did I do??? ...and how do I turn this display off?

Thanks in advance,
Beverly Howard

[Beverly Howard]

it is set talk... but, where is it getting turned on?

Never mind... I'll find it eventually ;-/

Beverly Howard

[Bernhard Sander]

Hi Beverly,

Post by Beverly Howard
it is set talk... but, where is it getting turned on?

SET TALK ON is the default setting. And it is scoped to a datasession.
If you create a new session (as does every form with private datasession, report
with private datasession etc) then within this session you have to SET TALK OFF
explicitly somewhere in code.

That's why I created an extra prg file with all the session scoped settings I
need in every session like SET EXCLUSIVE, SET DELETED, SET DATE, SET HOURS etc
and also some CURSORSETPROP. When starting a session, then I simply call this prg.

Regards
Bernhard Sander

[Gregory Adam]

'set status bar off ' may be the cause
--
Gregory
_

Post by Beverly Howard
Murphy is alive and well...
Thought I was going to be ready for a demo this morning and it seems that
I did something to turn on reporting similar to "set talk" but "set talk"
does not impact it.
What's happening is that the contents of all variables being populated are
being printed to the screen.
What did I do??? ...and how do I turn this display off?
Thanks in advance,
Beverly Howard

[Beverly Howard]

Thanks all...

I'm still not at home with private data sessions... somewhere in the
mix, talk got turned on and the default settings (my assumption) for the
project seemed not to work.

Found it by the fact that I moved "set seconds off" (new to DT fields as
well ;-) and discovered that it no longer applied to the form that I had
been testing as a standalone object.

Beverly Howard

[Bernhard Sander]

Hi Beverly,

Post by Beverly Howard
I'm still not at home with private data sessions... somewhere in the
mix, talk got turned on and the default settings (my assumption) for the
project seemed not to work.

The defaults for a new session are always the fox internal system defaults.
There is no way to define some kind of "user defined defaults" for new sessions.
You have to explicitly set your settings in every new session.
What you can store as "defaults" are only the settings for the first session
when you start the ide of foxpro. I think they are not loaded, if you start an
own foxpro application without the ide.

Regards
Bernhard Sander

[Beverly Howard]

Post by Bernhard Sander
The defaults for a new session are always the fox internal system

defaults. <<

Thanks... good information.

In this case, I'm trying to "embrace" the way vfp works other than fp,
so, for me, it's still a learning process to know what's happening
differently "by default"

In general, I am _very_ happy with the results of doing so on this
project. So far, the project has come together about five times faster
than I anticipated, surprising also because of the difficulties that I
had with my last project which was my first that was 100% vfp.

Beverly Howard

[Dan Freeman]

Post by Beverly Howard

Post by Bernhard Sander
The defaults for a new session are always the fox internal system

defaults. <<
Thanks... good information.
In this case, I'm trying to "embrace" the way vfp works other than fp, so,
for me, it's still a learning process to know what's happening differently
"by default"
In general, I am _very_ happy with the results of doing so on this project.
So far, the project has come together about five times faster than I
anticipated, surprising also because of the difficulties that I had with my
last project which was my first that was 100% vfp.
Beverly Howard

Most of us have a "sets" class that we instantiate inside each of our
form classes. The INIT issues the necessary SET commands so they're set
the way we expect them, and the destroy puts them back to what they
were before just to be tidy.

This class can then be re-used in forms, reports, and anywhere else you
want a "known" environment.

Dan

[Beverly Howard]

most of us have <<

These are on my list of things to do... one excuse is that I am waiting
to get a bit more proficiency as I know that when things like this are
written by me and work, they tend to not get polished ;-)

Thanks,
Beverly Howard

[Dan Freeman]

most of us have <<

These are on my list of things to do... one excuse is that I am waiting to
get a bit more proficiency as I know that when things like this are written
by me and work, they tend to not get polished ;-)
Thanks,
Beverly Howard

Perfectly valid approach, although with this one there isn't a heck of
a lot to perfect and a nice payback once it's in place. :-)

Dam

[Bernhard Sander]

Hi Dan,

Post by Dan Freeman
Most of us have a "sets" class that we instantiate inside each of our
form classes. The INIT issues the necessary SET commands so they're set
the way we expect them, and the destroy puts them back to what they were
before just to be tidy.

Since the per session settings are scoped to the session, there is no need to
clean up anything when the session is destroyed...
And re-setting more than the per session settings is maybe not a good idea in an
environment where the user can switch from some session to any other session.
But as very often: it depends...

Regards
Bernhard Sander

[Dan Freeman]

Post by Bernhard Sander
Hi Dan,

Most of us have a "sets" class that we instantiate inside each of our form
classes. The INIT issues the necessary SET commands so they're set the way
we expect them, and the destroy puts them back to what they were before
just to be tidy.

Since the per session settings are scoped to the session, there is no need to
clean up anything when the session is destroyed...
And re-setting more than the per session settings is maybe not a good idea in
an environment where the user can switch from some session to any other
session.
But as very often: it depends...
Regards
Bernhard Sander

I've never had a problem from it, and using the same class in places
where a private data session may not be an issue means cleaning up
after itself DOES matter.

So it may depend, but it has never caused a problem for me.

Dan

[Richard Stecenko]

I have a
form that calls another form to do the printing
that calls a report
that uses the reportlistener.

Just before the reportlistener thermometer appears,
a bunch of variables show up on the form surface:
listener.vcx
listener.vcx
End of Locate scope
.F.
.T.
.T.
.T.
gfxNoRender
listener.vcx
listener.vcx
listener.vcx
End of Locate scope
.F.
.T.
.T.
.T.


I've put a few set talks off but, I'm still getting this stuff.

The form that does the printing is an old one, originally programmed
in VFP 7 and upgraded to VFP 9; and it's not mine, I inherited this
application.

Any help would be appreciated.

Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Dan Freeman]

I vaguely recall seeing reports of this in a version of the
reportoutput.app pre-service packs.

Which one are you using?

Dan

Post by Richard Stecenko
I have a
form that calls another form to do the printing
that calls a report
that uses the reportlistener.
Just before the reportlistener thermometer appears,
listener.vcx
listener.vcx
End of Locate scope
.F.
.T.
.T.
.T.
gfxNoRender
listener.vcx
listener.vcx
listener.vcx
End of Locate scope
.F.
.T.
.T.
.T.
I've put a few set talks off but, I'm still getting this stuff.
The form that does the printing is an old one, originally programmed
in VFP 7 and upgraded to VFP 9; and it's not mine, I inherited this
application.
Any help would be appreciated.
Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Richard Stecenko]

Post by Dan Freeman
Which one are you using?

I'm using VFP 9.0 SP2.

The reportoutput.app is dated 15-Oct-2007

I think you are setting me on the right track, because this is the
first time I've worked with the reportlistener since setting up my new
Windows 7 computer.


Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Stefan Wuebbe]

Hi Richard,

I believe Brad Schulz has written a few things about that issue,
like this one: http://www.foxite.com/archives/0000204548.htm



hth
Stefan

Post by Richard Stecenko

Post by Dan Freeman
Which one are you using?

I'm using VFP 9.0 SP2.
The reportoutput.app is dated 15-Oct-2007
I think you are setting me on the right track, because this is the
first time I've worked with the reportlistener since setting up my new
Windows 7 computer.
Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Dan Freeman]

Post by Stefan Wuebbe
I believe Brad Schulz has written a few things about that issue,
like this one: http://www.foxite.com/archives/0000204548.htm

Ugh!

I knew I'd seen this somewhere but thought it had been fixed. ::sigh::

Dan

[Bernhard Sander]

Hi Richard,

Post by Richard Stecenko
I have a
form that calls another form to do the printing
that calls a report
that uses the reportlistener.
Just before the reportlistener thermometer appears,

The problem is, SET TALK is scoped to a data session and its default is ON.
So, the form with this output has its own data session. There it would be
necessary to SET TALK OFF somewhere. Or switch off the use of a private data
session for this form.

Regards
Bernhard Sander

[Richard Stecenko]

Hi Bernhard,

Yes, it's all about set talk off.

This project was originally written in VFP7 and the developer wrote a
"front end" for report printing. In forms with a private data session,
he created the cursor to be printed; then calls this common "front
end" form with a Default Data Session to print/preview the report.

When I SET REPORTBEHAVIOR 90 and started using the new report
listener, I'm getting this stuff showing up on the screen surface.

I really, really don't want to pull apart this old 'front end' form,
nor do I want to stop using the report listener.





Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Richard Stecenko]

Post by Richard Stecenko
Yes, it's all about set talk off.

Sorry, people, but I wasn't paying close enough attention.

It's not all about set talk off; there's also set console off.

Now that was 2 hours down the drain.

Thanks all for the assistance.

Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052