Hi Paul,


> 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.
>

Absolutely right! My mistake. I used LIST STAT. Sorry about that.

> 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.

True again, but is seems somehow less robust as a solution. Remember
that you are trying to trap a programming error. Some forms may be
closed, but not released, in which case you would not see the
datasession, but you could still have tables open.

> 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?

I think we have definition problems here. I meant (and regretted) that
datasessions fall into the OOP organization in VFP because you can only
create them as a property of a form object. On the other hand I
suspect that the developers of VFP have organized the datasessions as an
extension of the select handles. I suspect that they recompute the
select area on the basis of the datasession and the select variables and
use 'again'. This is pretty traditional FP stuff don't you think? so I
wonder why they did not give us full access to this information and
allow us to create our own datasessions, i.o. needing a form to do
this. One of those ideosyncraties that keeps us busy I guess. You did
ask for comments eh! :)

Marc


> /Paul