Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Methodology question
Message
 
 
À
10/01/2001 12:00:45
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00461641
Message ID:
00461700
Vues:
10
>>Hi everybody,
>>
>>We're using our own framework. In this FrameWork we have two Form classes, both of them have some code in Load event, which sets several common settings, e.g.:
>>set talk off
>>set ansi on
>>set exact on
>>set multilocks on
>>etc.
>>
>>Now, let's assume this situation, which happens in one of my application:
>>One Form calls another form.
>>The first form has private DS and the second has default in order to share calling form DS. In the first form I excplicilty set SET EXACT OFF, because I need it this way. The other form would override my settings in its Load event and even worse, the calling form now would have a wrong setting as well. What can you suggest to resolve this problem.
>
>Best way, IMO, is to revert to the good old practice we had in procedural days: leave the things as you found them. So, for any form which has a public datasession and does change the settings:
>
>in .Load, save the settings which could be changed, and (depending on what you want to do), call a method to set the new settings
>in .activate, call a method to set the new settings
>in .deactivate, call another method to restore the original settings
>
>While you could set and restore the settings in .load and .unload (or .destroy), I'm still inclined to think that a separate pair of methods would be better - you may need to call them in a different context, depending on what you do on your form.

Thanks, Dragan. This seems like a clean solution, but a little bit complicated.

Anyway, after I reported the problem to my colleague, who is responsible for classes changes, she reverted back this recent update, so now wgForm doesn't contain special code in Load at all.

I proposed less strict solution - make this change conditional (May be add a new Property to the Form, say, lSetSettings and operate depending on this property)...

Thanks again.
If it's not broken, fix it until it is.


My Blog
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform