Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Still problems with work areas
Message
De
26/05/2017 05:45:17
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
25/05/2017 14:14:54
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012 R2
Network:
Windows Server 2012 R2
Database:
Visual FoxPro
Application:
Desktop
Virtual environment:
VMWare
Divers
Thread ID:
01651367
Message ID:
01651522
Vues:
42
>Hi Dragan,
>
>So I wrote a utility program that I could call from a few points and I wrote out to a file all the datasessions and tables in each datasession and form info etc.
>
>Guess what: when the code fails, the current datasession (from SET("datasession")) is not the datasession of the form that I am calling the code from.

It's the datasession which was active when that object was instantiated.

Like I said, my solution was along the lines of separation between the visual and business objects. The biz objects are defined in prg files, so they are pretty lightweight, instantiate quickly and I instantiate them (as many as needed for each context) when I need them, so they all live in the same datasession.

Having global objects is fine as long as they don't have to do anything with the cursors opened by some other object - which then may be in a different DS. So you'll need to move some furniture around. I've used several frameworks in my time, but not VMP, so I can only guess how it does what it does. For starters, try not to keep that global object alive all the time, but rather create it when you need it, from within the form where you need it. Then it would run in the form's DS.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform