EinTerraner
Technical User
How can I determine the owner/form of a private data session?
ASESSIONS(A1) only shows the number.
ASESSIONS(A1) only shows the number.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Determine owner of private data sessions
- Thread starter EinTerraner
- Start date
- Status
Mike Lewis
Programmer
You can loop through all the open forms, testing each one's DataSessionID against the required value. Something like this:
Keep in mind that forms are not the only object that have a DataSessionID. Session objects and toolbars do as well, and also formsets (which you will probably never use).
Mike
Code:
lnID = 2 && this is the ID you are looking for
FOR EACH loForm IN _screen.Forms
IF loForm.DataSessionID = lnID
* this is the one you want
ENDIF
ENDFORKeep in mind that forms are not the only object that have a DataSessionID. Session objects and toolbars do as well, and also formsets (which you will probably never use).
Mike
Last edited:
- Thread starter
- #3
EinTerraner
Technical User
Ty, did not think about THIS near soloution ....(shame on me)
You're right. i dnt use FormSets and neither Sessionobjects.
Yepp, this i know.
You're right. i dnt use FormSets and neither Sessionobjects.
Chris Miller
Programmer
I wonder whether you need to know which sessions are private. A private datasession can becoma a shared one and you can let code act and look into any session with SET DATASESSION.
If you want to do something in a forms datasession, just make it a function/procedure/prg that form calls, and the code will act in the forms datasession. Or you create a class (based on custom, container or similar) and let it be instanciated on the form, therefore running in the forms datasession, no need to think about it.
The only situation is with an object that's not part of a form (or session or formset), where you'd first need to find out which datasession ID to switch to. And then you only need to know this, if you want to act in that session from outside. Like someone not being invited to a party causing some trouble.
By the way, even classes without the datasessionid property will exist and work in one datasession, when they don't start a new datasession themselves (which only forms, formsets or session classes do) they are bound to the datasession that's current, when they instanciate.
Since goApp, an application object, is the most typical class you create first, it'll run in datasesion ID 1 (unless you base it on a private session or form/formset with private session, of course) and won't act in any other later (private) datasession. That means the class you use for an application object will need to have the ability to switch datasessions, if it should work in private datasessions. On the other side, you decide for a private datasession to decouple from other datasessions and if you design goApp to enable session switching, you're breaking encapsulation rules, one or the other way. If you need that, it's perhaps worth thinking why and whether there's not a more straight forward solution not needing this.
And basing the application object on a session class is also not a bad idea to always be in a datasession no other object uses, unless you program with datasession switching. If you do without swithin, you have your own workareas, no CLOSE ALL or CLOSE DATABASES ALL and no automatically closing workareas data environments will interfere with.
And all that said, private sessions are not private the same way as protected or even private methods are only accessible for a class (or subclass) or local variables are only available local and public variables everywhere, any session can be switched to.
If you want to do something in a forms datasession, just make it a function/procedure/prg that form calls, and the code will act in the forms datasession. Or you create a class (based on custom, container or similar) and let it be instanciated on the form, therefore running in the forms datasession, no need to think about it.
The only situation is with an object that's not part of a form (or session or formset), where you'd first need to find out which datasession ID to switch to. And then you only need to know this, if you want to act in that session from outside. Like someone not being invited to a party causing some trouble.
By the way, even classes without the datasessionid property will exist and work in one datasession, when they don't start a new datasession themselves (which only forms, formsets or session classes do) they are bound to the datasession that's current, when they instanciate.
Since goApp, an application object, is the most typical class you create first, it'll run in datasesion ID 1 (unless you base it on a private session or form/formset with private session, of course) and won't act in any other later (private) datasession. That means the class you use for an application object will need to have the ability to switch datasessions, if it should work in private datasessions. On the other side, you decide for a private datasession to decouple from other datasessions and if you design goApp to enable session switching, you're breaking encapsulation rules, one or the other way. If you need that, it's perhaps worth thinking why and whether there's not a more straight forward solution not needing this.
And basing the application object on a session class is also not a bad idea to always be in a datasession no other object uses, unless you program with datasession switching. If you do without swithin, you have your own workareas, no CLOSE ALL or CLOSE DATABASES ALL and no automatically closing workareas data environments will interfere with.
And all that said, private sessions are not private the same way as protected or even private methods are only accessible for a class (or subclass) or local variables are only available local and public variables everywhere, any session can be switched to.
Last edited:
Chris Miller
Programmer
To illustrate the "every object lives in one session" stetement:
You can see it depends whether you run Createobject inside form1, form2 or from outside, which datasession it the created object belongs to, not only for objects, that are actual children of the forms (and have the form object as their parent property).
It all boils down to this, though: If you don't do anything special, every object falls into the right place (i.e. datasession) and therer are no surprises. that controls don't have access to the forms workareas. The way it's automatically working is so well designed, that you have to dig deep to break something on some other objects private datasession.
If you do things like creating a factory class by reading about design patterns (like the mother of all books about that by the gang of four) and your factory class is living in one session, be it datasession id 1 or any private session, you suddenly get struck by all your class instances living in that same datasession, whether they should or not. And that means it's no good idea to reinvent the wheel by a factory that you make the only point of all object creation, there are the several object creating functions and methods and you just need to know which of them to use for which objects. On the other hand knowing all that you can take advantage of a factory that knows about where which classes are defined and how to create them with which requirements to be fullfilled if you program it in a way that it delegates the actual object creation to whichever class should actually do it. And then also don't exaggerate by letting the factory create controls of forms. by interpreting the factory pattern principle very strict. You simply design forms with controls and they are therefore part of the form and there's no need for a factory controlling the controls creation, monitoring or overlooking it as a god (manager) of all objects created. Also see discussion about god classes, for example as simple as by Wikipedia.
So in that respect (design patterns): It's good to know them, but also know VFP in and out to know how to apply the patterns within the VFP language. I'm not saying there are no pros in creating something like abstract classes of each type of design pattern to have a concrete implementations of the pattern and a class that overlooks and enforces the rules of its own pattern. But it has to be done in a way the VFP language allows it with its design, no matter if you call datasession dependency or membership a design flaw or not, for example.
And sorry, you didn't mention patterns, a factory or anything like that, i's just a good opportunity to talk about this. I have the feeling your question about determining which form has a sepcific datasession is about wanting to switch to it and influence it from outside, design a god''/manager class that can do so and by that break some of the principle of OOP, no matter if you think of core OOP principles or in terms of design patterns and espcially the factory pattern.
Code:
oF1 = CreateObject("myform")
oF2 = CreateObject("myform")
oF1.addchild("child1","Anything")
oF2.addchild("child1","Anything")
oD0 = CreateObject("Anything")
oD1 = oF1.createdetachedobject("Anything")
oD2 = oF2.createdetachedobject("Anything")
* expected output 1,1,2,2,2,3,3,3 (unless you start with multiple datasessions already)
* everything in the default (1) datasession
? Set("Datasession")
? oD0.ShowOwnDatasession()
* oD0, created in the main code, is also part of the default datasession ID 1)
* everything in the same session as form1 (private Datasession ID 2)
? oF1.datasessionid
? oF1.child1.ShowOwnDatasession()
? oD1.ShowOwnDatasession()
* everything in the same session as form2 (private Datasession ID 3)
? oF2.datasessionid
? oF2.child1.ShowOwnDatasession()
? oD2.ShowOwnDatasession()
* oD1 and oD2 are no children objects of form1, still are created in the same data session id
Define Class myform as Form
datasession = 2 &&private
Procedure addchild(name,class)
This.AddObject(name,class)
EndProc
Procedure createdetachedobject(class)
Return CreateObject(class)
EndProc
Enddefine
Define Class Anything as Custom
Procedure ShowOwnDatasession
Return Set("Datasession") && show current (own) datasessionid
Endproc
EnddefineYou can see it depends whether you run Createobject inside form1, form2 or from outside, which datasession it the created object belongs to, not only for objects, that are actual children of the forms (and have the form object as their parent property).
It all boils down to this, though: If you don't do anything special, every object falls into the right place (i.e. datasession) and therer are no surprises. that controls don't have access to the forms workareas. The way it's automatically working is so well designed, that you have to dig deep to break something on some other objects private datasession.
If you do things like creating a factory class by reading about design patterns (like the mother of all books about that by the gang of four) and your factory class is living in one session, be it datasession id 1 or any private session, you suddenly get struck by all your class instances living in that same datasession, whether they should or not. And that means it's no good idea to reinvent the wheel by a factory that you make the only point of all object creation, there are the several object creating functions and methods and you just need to know which of them to use for which objects. On the other hand knowing all that you can take advantage of a factory that knows about where which classes are defined and how to create them with which requirements to be fullfilled if you program it in a way that it delegates the actual object creation to whichever class should actually do it. And then also don't exaggerate by letting the factory create controls of forms. by interpreting the factory pattern principle very strict. You simply design forms with controls and they are therefore part of the form and there's no need for a factory controlling the controls creation, monitoring or overlooking it as a god (manager) of all objects created. Also see discussion about god classes, for example as simple as by Wikipedia.
So in that respect (design patterns): It's good to know them, but also know VFP in and out to know how to apply the patterns within the VFP language. I'm not saying there are no pros in creating something like abstract classes of each type of design pattern to have a concrete implementations of the pattern and a class that overlooks and enforces the rules of its own pattern. But it has to be done in a way the VFP language allows it with its design, no matter if you call datasession dependency or membership a design flaw or not, for example.
And sorry, you didn't mention patterns, a factory or anything like that, i's just a good opportunity to talk about this. I have the feeling your question about determining which form has a sepcific datasession is about wanting to switch to it and influence it from outside, design a god''/manager class that can do so and by that break some of the principle of OOP, no matter if you think of core OOP principles or in terms of design patterns and espcially the factory pattern.
Last edited:
- Status
