It works with SET CONSOLE OFF (which I assume many will put in a error trapping routine)
prior to displaying status.

>Well, you should have eventually run into problems with DISP STAT
>wanting a keystroke. LIST STAT should have been used instead. But
>that's another matter.


>> Back in the 2.6 days, when there _was_ only one datasession available, I
>> used to dump a display status into an alternate file. It may not be very
>> elegant, but since it is for my own consumption in maintenance, it is
>> appropriate, and face it, in cases of program errors, disp status gives us
>> plenty of information at a very low development price.
>
>Well, you should have eventually run into problems with DISP STAT
>wanting a keystroke. LIST STAT should have been used instead. But
>that's another matter.
>
>> ... and George, I think you are right, if we want the same functionality
>> in VFP, we will have to work for it and develop something along the lines
>> of what you suggest. It seems silly though, because datasessions as a
>> concept is related to the database rather than to oop, so why is there no
>> way programatically, (from the menu you can under window/datasession long
>> after the owning objects are dead and burried!) , to access existing
>> datasessions?
>
>By using the _screens.forms(x) array, you do have full access from any
>form to the datasession and, in fact, any other property or method, on
>any other form.
>
>And I disagree with your comment that DataSessions are related to
>databases, rather than OOP. I would suggest that they are related to
>_neither_. You can't subclass them, you can't change their behaviour,
>etc. so they are clearly not OOP based. Additionally they aren't
>database (.DBC) related because you can have tables from multiple .DBCs,
>free tables, etc. in them, so they aren't related to the idea of a .DBC.
>
>Comments?
>
>/Paul