>>>>>>>>I created a custom class that in its Init() event I do all the SET commands for the data environment. This class was then added to my form class which has a private data session. This gives me one place to manage all the SET commands for a private data session.
>>>>>>>
>>>>>>>First, thank you. Do I understand correctly that all of your forms are based on the form that has this custom method? For example, in my app almost all forms are based on a form myform. So I could then add a custom method to this form to call in the Init of the form. Is this the approach? Otherwise, I don't understand what you mean by "a custom class that is its Init() event".
>>>>>>
>>>>>>I normally set all private DS settings in the Load event, Init may be too late.
>>>>>
>>>>>I wonder why there is no global SET DATE (or SET CURRENCY) setting that would work without code in every Load method. For example, I would be surprised if the European developers of VFP have to code it in every Load method. It probably works for them out of the box. Or is it because they buy a different version of VFP? or their settings inherits from the their Windows OS?
>>>>
>>>>It is because they use a form's class. They set all their settings in the Load of the base class and that's it. That's the normal practice.This is what we have here as well.
>>>
>>>This is what I plan to do too. Most if not all of my forms are based (child classes of) on a class MyForm in MyBaseClasses.vcx. And I will put the code in the LOAD method of the MyForm all SET DATE, etc.
>>>Thank you.
>>
>>Similar but cleaner would be to create a separate class that handles those settings. In the Load of the form you can instantiate this class, but the logic itself does not need to be handled in the form itself. This way you avoid the swiss army knife pattern.
>>
>>As a side effect you can use the same class then from other locations where you don't inherit from that form. If the settings change you only need to change the settings class and the new behavior will be applied in all places where this class is being instantiated.
>
>It makes sense. But I want to be sure that the separate class (which I will put in a .PRG) looks something like this:
>

>DEFINE CLASS GlobalSettings As Custom 
>    Procedure INIT
>            If InEurope   && some global setting
>                 Set Date to British 
>                 Set Currency to "Euro Symbol"
>                 Set point to ","             
>           endif
>ENDDEFINE
>
>*-- Then instantiate it in the LOAD method as
>oGlobalSettings = newobject("GlobalSettings","mysettings.prg")
>
>

>
>Is this (above) what you are talking about?
>Thank you.
>
>UPDATE. And just to add to my message. Why not using a Function instead of a class? That is, if the above makes sense, I could put the code in a function and simply call it from the Load method.

That is the way how I would do it.

There are almost always advantages of a class over a function. For instance you can create properties and methods that can encapsulate more complex behavior. Also you can subclass the object and create factory methods to deal with changing requirements more efficiently. Alltogether it helps you to implement modern design patterns that keep your code more clean and more easy to document.

The only times you really need a function is when you want to do the function call inside of a query or command where you don't want to instantiate an object.

I have a class that sets the date based on a certain situation:

DEFINE CLASS DateSetting AS Custom
   Value = ""
    PROCEDURE INIT
        THIS.Value = SET("DATE")
    ENDPROC
    PROCEDURE Set
        LPARAMETERS tcValue
        SET DATE &tcValue
    ENDPROC
    PROCEDURE Destroy
        LOCAL lcValue
        lcValue = THIS.Value
        SET DATE &lcValue
    ENDPROC
ENDDEFINE

So what the class does, because the user can set his own Date setting preference, in a certain report I need to display british date:

LOCAL loDateSetting AS DateSetting OF Utils_DateAndTime.vcx
loDateSetting = NEWOBJECT("DateSetting","Utils_DateAndTime.vcx")
loDateSetting.Set("British")

Report Form MyBritishReport PREVIEW

RETURN .T.

So the user setting will be overwritten for the report, but autoamatically reset after running the method.