>>We already have hundreds of forms designed before the themes were suported, and some (probably most) forms do not look good with themes.
>>For this reason, we would like to default to themes off, and give the user the option at the form level. As it is now, we can only default to themes on.
>
>Not so. Because forms and each property have individual Themes properties, you can get what you want. Set Themes to .F. in your base form class. Set the Themes property (or Style property, where that's the right one) to True for the base control classes. Now, all it takes to turn themes on is to set Form.Themes to .T. for the individual forms.
>
>To do this universally, add code in the base form class that checks for a property of the application object or for a global variable and turns form.Themes on if it's found and .T.
>

The above works... unless the _screen.themes is .F., in which case you can set themes all you want at class level or for objects, it will not matter.
Te very fact that you need all these changes should tell you that the current design... could be improved.
Having _screen.themes take precedence over object.themes is like your object method code not being executed because there is code in the class method.


>The key point in all of this is that if the user has turned themes off at the Windows level, your application has no business using them, and more importantly, can't.
>
>I guess I see the point if your application is running as part of another application, but from the user's perspective, they're really both part of the same thing and should behave the same way.
>
>The bottom line is that you're dealing with a hierarchy here. The top level is Windows. If Windows has themes turned off, your application simply can't use them.
>
>The next level is the VFP executable. If themes are turned off there, your forms can't use them.
>
>Next is the form. If themes are turned off at that level, the controls on the form can't use themes.
>
>The bottom of the hierarchy is the individual control. If themes are on at all the other levels, the control can use them.
>

The key point... missing here is that the user has access to Windows themes, but does not have access to _screen.themes in VFP, unless you make it part of the UI – a messy solution for the user to have to deal with two properties _screen.themes and, say, form.themes.
My key point is that, in VFP the object.themes should overwrite _screen.themes, regardless of what _screen.themes is.



>Tamar