Do containers have data sessions? 2

[MrDataGuy]

I hope I am missing something simple, e.g. a property name that I have forgotten. OK here is the question; Can I give a container its’ own datasession? For example a form can have a data session and of course the Session class has one.

Why am I asking? Well I have a form that will have a pageframe with a number of container objects on each of the pages. These objects will be nearly the same with several cursors. It would be great if the containers could reuse the names of the cursors, but to keep things straight I need them ‘walled off’ from each other via datasessions.

Anyhow is there a way to give a container its own data session?



Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Olaf Doschke]

No chance. And even if you'd make use of the session class, you'd need to switch between datasessions when switching between the pageframes and I expereinced unstable behaviour of VFP when doing this.

You might still give that a try, but I'd rather go about this by prefixing alias names per page/container.

Bye, Olaf.

 

[Mike Lewis]

One possibility might be for each of the containers to instantiate an object, based on a session class, that would handle all its data-handling. The containers could be based on the same class, with completely common code, but each would have its own session object.

But that's not ideal. Every time the container called a method of the session object, it would have to switch data session, which is ugly.

It might be simpler to keep everything in the underlying form's data session, with each container generating its own cursors, and using a naming convention to keep them separate. For example, each cursor could incorporate the number of the containing page in its name.

You might end up with a large number of cursors in the same data session, but that shouldn't be an issue.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[MrDataGuy]

naming convention to keep them separate"
Yes that is what I am doing. I was hoping thou that I had missed something obvious and a better standard solution existed.

I guess I will add this idea to my "dream -list": Every object has by default it's own data session but at the same time an easy way to access its' parent's (and Parent's parent's) data session. ( And on a completly different thread" I wish there was a This.Container key word like there is a This.Parent word <smile> )

Thanks for the confirmation that the road I have taken is the right one!

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Olaf Doschke]

In regard of object hierarchy This.Parent is This.Container always, and you can determine if the parent is a container like object by checking it has a Objects() collection property or not.

In regard to Datasessions you may rather mean This.DatasessionID or such, and it would be nice if that was not just a numeric ID but a reference.

Indeed there is a not so obvious binding of objects towards datasessions, not only in regard to controls on a form. Eg if you instanciate a custom class this is living in the datasession it's created in. Calling a method in that custom class can mean an indirect change of datasessions as a side effect and this can hurt, if you don't expect that.

Take a look at the following:

Clear 

Local lnCurrentSession
lnCurrentSession = Set("Datasession")
? "current session", lnCurrentSession

* Create Object in the current session
oObj1 = CreateObject("MyCustom")

* Create a new Datasession
oSess = CreateObject("MySession")
? "new session", oSess.DatasessionID

* Change To that Session and Create another Object in the second session.
Set Datasession To oSess.DatasessionID
oObj2 = CreateObject("MyCustom")

* Change back to the previous session
Set Datasession To lnCurrentSession

* Create a third object in the new session by creating it within the session object:
oObj3 = oSess.CreateMyCustom()

* Display the Sessions the objects belong to
? "Object 1 session",oObj1.GetSession()
? "Object 2 session",oObj2.GetSession()
? "Object 3 session",oObj3.GetSession()

Define Class MyCustom as Custom
   Procedure GetSession()
      Return Set("Datasession")
   EndProc 
EndDefine 

Define Class MySession as Session
   Procedure CreateMyCustom()
      Return CreateObject("MyCustom")
   EndProc 
EndDefine

And you can give that another twist if you'd generate a child object within the MySession class via _Screen.AddObject("MyCustom1","MyCustom") within MySession, as you then create a child object of _Screen being in another datasession as the _Screen itself is (_Screen.DatasessionID). And that's where the trouble starts. It's a little bit of Fringe, if you know that tv series .

Bye, Olaf.

 

[MrDataGuy]

I should mention that the containers call Biz Objects that are based on the session class. (e.g. they have their cursors nice and protected in their own datasessions) I just like the idea of keeping data as local to the objects that need them as possible and away from objects that do not need them. Since there are many tables that only each page frame needs to know about I had wanted a way to limit the scope of the cursor, back to the datasession question. Luckly this is not a 'if I can not fix this my app will not work situation' I am just polishing the cannon/bowling ball.

Side comment the this.container is wanted because sometimes the code is several level deep and instead of this.parent.parent.parent.something or Thisform.cntFoobar.cntSubFoobar.Something. I would like This.container (Like one can be several levels down and say This.Form.) I am well aware that this is not going to be added to the language for several reasons, but you have to let a guy dream once and awhile. <wink>

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Olaf Doschke]

In regard to This.Container as an analogon to Thisform: How would you define where in the hierarchy to stop going up?

Think about the outer container of a container class?
Then do this: In the init of the container set
goThis = This and in the Init of each subobject do This.AddProperty("Container",goThis).

Bye, Olaf.

 

[MrDataGuy]

This.AddProperty("Container",goThis)"

Slap my forehead, Yes that would do it! A 'pointer' property back to the containing object, set it once and then refer to it.

Good suggestions! (of course having it built in to VFP would be even better <wink>, I am sure MS will get right to to it and send out an upgrade. )

Q: How would you define where in the hierarchy to stop going up?

A: When (in this situation ) I say 'container' I mean the visual container class specifically. Not things like forms, pageframes etc. that contain other objects. I guess thinking about it more I want ThisContainer, ThisPage, ThisPageFrame, ThisCommandGroup etc.

Yes I can see an issue if container was inside another container inside another container etc. Therefore I want the process to stop at the first level up of container.

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Olaf Doschke]

Actually, if you want it only one level up in regard to some container class, you could go about it this way, as a sample in regard to the Pageframe

In a vcx add each baseclass, only use these control classes or subclasses of it in your forms, add a ThisPageframe property to any class of that library and let it always have an Access method, ThisPageframe_Access.

In that Access method the code should be:

If Type("This.Parent")="O" 
   If This.Parent.Baseclass = "Pageframe"
      Return This.Parent
   Else
      If Pemstatus(This.Parent,"ThisPageframe",5)
         Return This.Parent.ThisPageframe
      Endif
   Endif
Endif

Return .NULL.

untested. I'd rather not use it. It surely has the disadvantage of no intellisense working on This.ThisPageframe.

And actually if you're in need of this very often and desperately, you're having too much coupling of objects with each other, OOP means encapsulation, loose coupling, as few depdencies as possible and if by reference, binding events and by design patterns as the mediator pattern.

Bye, Olaf.

 

[MrDataGuy]

need of this very often and desperately" No, just a side want. Thanks for the ideas/suggestions/etc.

"OOP means encapsulation, loose coupling, as few depdencies as possible" Very true!

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com