>>>>>>1. Something in our mis applications startup turns the _screen.themes to .F. Code reference did
>>>>>>not find any explicit _screen.themes. Do you know what might set _screen.themes to .F. other
>>>>>>than the code assignment?
>>>>>
>>>>>SYS(2700) is the only thing I can think of that would do this.
>>>>
>>>>I found a _screen.themes = .F. somewhere in our code using debugger - and then found that code reference had it too...
>>>>
>>>>>
>>>>>>2. From the help file I did not understand that _screen.themes setting overwrites everythig below. The
>>>>>>way it is, you can only have themes as default for everything, and classical style for specified objects,
>>>>>>but not classical as default and themes for specified objects. I think I'd like it both ways.
>>>>>
>>>>>I disagree. If you want this, set Themes to .F. in your baseclasses, and then set them on for selected classes. If you turn Theme support off at the screen level, how are you supposed to turn it on later?
>>>>
>>>>That's exactly what I did: themes=.f. in form class, and the checkbox value .f., and all is well now - thanks for assistance.
>>>>
>>>>I still think that if you can say "disable themes for this form when they are enabled for screen", you should be able to say "enable themes for this form when they are disabled for screen". In other words, when I set a property of an object that should not depend of a property of another object. If you put code in a method, that code is executed regardless of what happens elsewhere.
>>>
>>>Doru,
>>>
>>>IMO, this is strictly a user option. I've got an application that runs under XP both with and without themes. Fox determines whether or not themes are enabled, and draws the objects appropriately. For example, I've got an app that has both the form and _Screen setting for themes equal to true. Under XP, if themes aren't enabled, you don't get them. If they are, you do.
>>
>>George,
>>I think that what I say, not only is a better design of the VFP themes support, but is better from a "user option" pov.
>>
>>In your example the user has the option only at the XP level. You dont realy use the themes property of VFP objects, and I assume you don't have anything in your UI to allow the user (the REAL one, not Fox) to change a particular form apperance. Your user gets all or nothing, which is surely a more consistent UI, but there is no user control from inside the application. Also, if your application is part of another application which sets the _screen themes to .F., your user will not get themes even if XP themes are enabled.
>>
>>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.
>
>Doru,
>
>With all due respect, let me give you my take on this.
>
>What's most important is what the application does. If it does it properly, IOW produces the right results, then the visual appearance is strictly secondary, especially if the user has chosen an unattractive theme.
>
>I learned a long time ago to worry only about what I can control in programming and not worry about what I can't.
>
>Now, I'll freely admit that I follow the Windows UI guidelines as outlined in the "Windows User Experience" in the MSDN library. Given that and all of the above, if the user doesn't like the appearance, I'd say that it's pretty much their problem. Giving them the option to turn themes off in one program doesn't fundamentally enhance its utility.

I believe that UI is as essential as what the app does - imagine you label your Yes button with "No" ;)
I also believe users benefit from having control over things like colors and themes.
I can live with the current design of themes support in VFP, and I’ll stop worrying about what’s so hard in getting my point.
Thanks, I enjoyed the exchange.