>Hi Mike,
>
>I think often enough such a PushPop-Class is oversized for just remembering one setting.
That's a matter of opinion. I don't see anything wrong with this technique especially since the destroy resets whatever it tracked. There is a savings and a safety factor.
I've titled the thread to suggest I'm trying to put a factory object to practical application, not just theoretical. This is a good exercise as it brought out your points below.
I'll play with this some more and get back to you!
Thanks
>That aside in this case it's even useless. Even if the PushPop object is generated in the current datasession, it will not reset the datasession of THIS (being the object generating the PushPop class instance). A SET DATASESSION command done in the destroy of such an object will only set it's datasession shortly before it dies, which does not reset the datasession of it's creator!
>
>In that respect the current datasession should be seen as a property of each object instead of an object containing other objects. Such a PushPop class IS okay especially for session dependant settings, but not SET("Datasession"), it's useless for that setting!
>
>My code also was misleading. Let's say you have some dataobject, which queries some table and you want to use that in several forms each with their own private datasession. Lets call that dataobject goApp.oData, then my code should have been:
>
>
>procedure thisform.cmdGetData.Click()
>goApp.oData.setDatasession(set("datasession"))
>goApp.oData.getSomeData()...
>goApp.oData.resetDatasession()
>>
>Now let's take a look into the goApp.oData object:
>
>procedure init()
>this.datasessionID = set("datasession")
>
>procedure setDatasession()
>lparameters tnDatasessionID
>set Datasession to tnDatasessionID
>
>procedure resetDatasession()
>set datasession to this.datasessionID
>>
>So the call of setDatasession() will pull the goApp.oData object into the same datasession as the form, the getSomeData() call will perhaps generate a cursor within the forms datasession. How would a PushPop-Class help here, to then reset the datasession? if it does a SET DATASESSION in it's destroy, that will neither effect THIS(FORM) nor the goApp.oData object!
>
>The setDatasession() method is useful for any further calls into goApp.oData until you call goApp.oData.resetDatasession(), and you might not even need the resetDatasession() method, if you use setDatasession() anywhere before you call some method generating data in it's current datasession.
>
>you are thinking about (not literally but in concept):
>
>oSetPushPop=createobject("SetPushPop")
>set datasession to 1
>goApp.oData.getsomedata()
>* end of method, datasession reset by destroy of oSetPushPop (? no, it's NOT reset!)
>>
>oSetPushPop is created within the current datasession, so it remembers that correct datasession. As you set datasession to 1, the oSetPushPop object remains in the previous datasession, it does not follow to sessionID 1, as a SET DATASESSION command does only set the datasession of the current object and not of all objects generated by the current object, it's scope is limited to THIS only. That's why with the destroy you don't reset the datasession of THIS, the datasession of THIS remains 1. That's why such a PushPop object doesn't help here.
>
>And as it's also recommendable to let a form stay in it's datasession, we pull other objects into this datasession, that's the way to go.
>
>Connecting this with the factory object: The factory generates objects in the datasession the factory is in. So you can generate objects having a setDatasession() method, with which you can switch the objects to other datasessions after their creation, as you like, which makes them usable in any datasession without generating several instances of them for each datasession. You can also let the factory have such a setDatasession() method to set the datasession before calling the method of the factory generating an object.
>
>Bye, Olaf.
