I've lost my way with TALK output 1

[Bryan - Gendev]

When I create an exe for my single form app and start processing tables I am seeing 'output' on my main forms area which is no longer visible. This is like writing to std out as I understand it.

I don't see this when running in my development environment.

The output flashes very quickly but includes messages such as '1 replacement made'

I have SET TALK OFF in the init of my form.

How can I turn this off and get 'silent' processing please?

GenDev

 

[Olaf Doschke]

Luckily there is a switch hindering such output, simply set your main forms AllowOutput to .f.

You may not need to dig deeper why it happens then. I don't think anything else but TALK is causing such output, the only thing known to unintendedly turn on TALK is some reportlistener you can fix. I don't remember the detail, but do you use reportlistener at all? Anyway, even if somehow TALK is set ON again, that won't put output on the form. It would then go on _screen, which you should have turned off in a single form app.

Bye, Olaf.

 

[Olaf Doschke]

Cold it be in the code you copied for the status bar redirection?

Bye, Olaf.

 

[Bryan - Gendev]

Thanks Olaf,

Perfect!

I haven't used any Status Bar codes yet.

GenDev

 

[Mike Lewis]

One other point to keep in mind is that TALK is scoped to the data session. If you turn it off in the main program, you might still need to turn it off in individual forms. I always do that in the Load event of my base form class.

But setting AllowOutput to .F. (at the base class level) also makes sense.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Good point. In this case gendev SET TALK OFF in form init, that's sufficient it's a setting for the form data session. The source of the messages is still not revealed, but doesn't matter very much. Indeed writing to the hidden _screen also takes time and in case output makes the previous output scroll that can take up quite some time. Not sure if that also is the case, when _SCREEN is invisible.

Bye, Olaf.

 

[Dan Freeman]

Setting talk off in INIT could still cause output in a private data session if there's any manipulation in form load.

Setting AllowOutput does away with the result, but it's important to understand the cause too.

 

[Mike Lewis]

I do it in the Load rather than the Init because lots of other code might execute before the Init (of the form), in particular the code in the Inits of the individual controls. But the general principle is the same.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Load is first, indeed. Simply memorize LISA - Load, Init, Show, Activate.

But wouldn't the form need to be visible for ouput to go there? The form only gets visible after Init, doesn't it?
I simply tested ? "Test" in Load and that prints on _screen, the form isn't yet available for output to it, even if I explicitly AllowOutput.

Bye, Olaf.

 

[Mike Lewis]

Yes, it's true that the form only becomes visible at the end of the Init. In that case, any TALK output generated before the Init won't have any effect.

But isn't it the case that, during the Load, the calling form (if any) is still the active form, and the one that would receive the TALK output? I'm not sure about that. I'll test it when I get time. But I do know that, during the Load event, _SCREEN.ActiveForm still refers to the calling form, not the form whose Load is executing.

Not that it matters that much. In my framework, TALK is set off in the base form class, and so applies throughout the application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What you say is right, the previous or yet still current form will get TALK output, if at all (normally it goes to status bar, only a few things go on a form). As this is a single form app the only other thing is the _screen, but in principle you can get output on a form caused by the form called, because the next form only gets visible after init in calling show or the automatic show DO FORM does.

That makes it essential to set TALK OFF in a forms Load event, to prevent output to the active form, too. But only, if there is a previous form.

Bye, Olaf.

 

[Dan Freeman]

But the point remains that the form's INIT is too late in the sequence.

The perfect location is actually in the DE load, since that's where the command is actually scoped, but not many people (that I've seen) actually subclass the DE. It's more likely to be "universal" when done in an app's form classes.

 

[Olaf Doschke]

You mean DE Init, DE has no Load event.

Yes, I also never subclassed DE, using form classes I never used DE myself, only a framework I used.
But there is another thing we did even before the visual data environment class was available: Subclassing the session class.

What we did is creating a form handler, that did create a session class before creating the form in it. All our forms classes had their datasession property set to default data session. So whether the form ran in default or private data session was controlled by first creating a default or private session in the form handler. We called it "session bubble", the form handler may also instantiate several forms in one session and so you had something like a formset with this session as the root object, without the downsides of the formset. The concept worked very dynamically and all session dependant settings like TALK or DELETED where done in the two session base classes.

As said, this is something you can also do in older VFP versions, the session class existed before the visual dataenvironment class, you only don't have a visual canvas and many of the DE properties handling initially selected alias, table opening, etc., but you of course have Init and Destroy.

In the help it's misnamed "Session Object":

https://msdn.microsoft.com/en-us/Library/fy7ybd0a(v=vs.80).aspx

Besides some other classes (eg relation) it's not available as visual base class, you can only define it in a PRG via DEFINE CLASS. You need to define two base classes for private and default datasession. You might make use of SET DATASESSION and let a private datasession merge with any other, that's not recommendable, though, as you then have an orphaned datasession and the object maintaining a datasession is living in another. On the other side you can create many default session objects, even if that means it's having the same datasession ID than another session object, that's it's nature and you still may have seperate root session objects for some forms in the same datasession. It can get confusing, but also is helpful to handle several form sets.

Bye, Olaf.

 

[Olaf Doschke]

I just extended my test form and indeed the event order of Data Environment also doesn't start with Init. What is earlier is DE BeforeOpenTables, that's also mentioned in the VFP help. And Form Load then is before DE Init. If you put a ? command in all these events or methods, OpenTables even comes before BeforeOPenTables, and as far as I remember this is not wrong, it's just the base behaviour of the BeforeOpenTables event to call the OpenTables method, if AutoOpenTables is .t., which makes OpenTables act automatically, like an event. This mixture of event and method is another of those historically grown VFP quirks.

Anyway, you're right, Form Load is not first.

Bye, Olaf.