>>>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.
>>>
>>>I make a general assumption, but I'm not 100% sure, so I ask your advices:
>>>-------------------------------------------------------------------------------
>>>Let's make this Load code conditional (in wgForm Load event) and execute it only in case Form based on wgForm has a private DS (common case). BTW, this may apply to BaseForm as well, as I just realized.
>>>
>>>This is probably a GENERAL RULE: if Form uses Private DS, it should set settings. If it uses Default DS, it usually means, it wants to accommodate the settings on the calling form/class/etc., so don't change the settings.
>>>------------------------------------------------------------------------------
>>>Thanks in advance.
>>
>>Hi Nadya,
>>
>>The way I've always approached this is to assume default SET commands will be global for the application, so I include them in a MAIN.PRG that executes upon start of the app. (I'm assuming this is a project that you're compiling into an executable.) If you really want to mess with SET EXACT in a form with a private data session, create a form class with SET EXACT ON in the .Load(), and SET EXACT OFF in the .Destroy(). But you'd have to use the private DS form when calling a child form to keep consistency.
>>
>>Another approach might be to keep SET EXACT OFF, do your SEEK(), then check the seek value against the field with "==" to see if they match exactly. Of course you'd also have to check for EOF.
>>
>>I've always kept SET EXACT OFF in my apps since it seemed to more often than not was the behavior I needed for my apps.
>
>Hi Henry,
>
>In the main application main program we issue couple of SETs commands, and, BTW, the default state for our system is SET EXACT ON (which I personally don't like much, especially because the system currently doesn't care about restoring settings after it finishes, so I have to issue SET EXACT OFF in command window). The same number of set's commands are repeated in BaseForm.Load event. We have another form class called wgForm. This is a replica of VFP Base Form class with only two properties set (ShowToolTip and DS set to private). Recently my colleague added the same code in Load as we have in BaseForm.Load, but I immediatelly found a case, where this would cause problems, so my colleague will revert these changes back to its original state (no code).
>
> As a simple solution here would be a logical form property, which tells us, do we need to change settings or not...

You could also consider creating a privatesessionsets class. This class would have properties for all the private settings. You can drop it on your form class however, don't drop it on the child form class.

Or, you could as you said, do something like...

If ThisForm.DataSession = 2

ThisForm.AddObject('privatesets','privatesessionsets')

EndIf
*************
BOb