Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Dangling Datasessions
Message
From
10/10/2004 08:55:45
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00949468
Message ID:
00950248
Views:
16
>Gregory,
>
>>
>> Good luck. I know it may take some time. Oh and do share
>> the results, maybe there's point 4)
>>
>
>Arrrghh!!
>
>OK, here it is: In order to be able to run isolated forms and processes during development (and for safety-reasons during runtime), most of my classes and forms check if everything is as they need it. There is an Application-Object, a global Eventhandler, one or the other procedure that needs to be set in order to run everything smooth.
>
>so there is a call like
>
do CheckEnvironment in PROC_SCHEDCUST.FXP  && <-- Don't want to check wether the proc. is set, so call
>                                           &&     the method directly with the IN clause.
>
>and this of course does something like
>
if type("goApp") # "O" or isNull(goApp)
>    public goAPP
>    goApp = NewObject(ccApplicationClassName, ccApplicationClassLib, "", gc_ThisINI)
>endif
>
>!BINGO!
>In "real life" in the EXE this actually never happens as this stuff is checked and created from the main prog and therefore in DataSession 1.
>
>Interestingly enough, although the App-Object for instance is NOT a session it still runs in the session it's been created in, even if the form that caused the "trouble" is gone for ages - just as You already mentioned it with the SCATTER MEMVAR NAME.
>
>Not really surprising if You think of it, but!, You need to think of it to avoid it ;-)
>
>I added a small method to the application-Class, that shows the effect.
>
>
PROCEDURE MySession
>    acti screen
>    ? "Hi, My name is "+ this.Name +" and I am currently working in Datasession "+ trans(set("Datasession"))
>ENDPROC
>
>BTW, in contrast to Dangling References, releasing the affected Objects will properly close the "Dangling Datasession".
>
>For all the others, that possibly but hopefully never trap into this, here the solution:
>
>Put your global stuff into a Method that checks the current DataSession and if necessary changes it to 1. At the end reSet it to the correct DS.
>
>Something like this
>
>
>LOCAL lnWasSession
>
>lnWasSession = set("DATASESSION")
>
>if lnWasSession # 1
>    *acti screen
>    *? "Session: ", lnWasSession
>    set Datasession to 1
>endif
>
>if type("goApp") # "O" or isNull(goApp)
>    public goAPP
>    goApp = NewObject(ccApplicationClassName, ccApplicationClassLib, "", gc_ThisINI)
>endif
>
>....
>
>*-- and ReSet the DataSession
>set Datasession to lnWasSession
>return .T.
>
>
>Thanks for giving me a hand on this.

Frank,

That is why I create the oApp in the Default datasession, ie when I open the database.
I do by the way call some methods of the app in the form's load to set a number of things that are scoped to the datasession.
Since I call an object's method, the code would be executed in one of the object (ds 1)
Hence the objects code sets the DS to the one of the form, executes the code, and switches the ds back to its original


Once the object has been created, it can add/create other objects. They will be created in the datasession where the object (executing the code) was created.

Glad to have been of some help
Gregory
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform