My reading of Calvin's blog was that if you have overridden BorderStyle at design time, the Properties field of the form record in the .scx will have DoCreate, then BorderStyle. The workaround is to switch this order. In my case, BorderStyle is not overridden at design time (only at run time), so it never appears in the Properties field for the form record, and thus there is nothing to rearrange.

The reason I changed BorderStyle to 2 in the Init of forms that were not to be resizable is so they were resizable at design time. So it looks like I will need to either:

1. Change BorderStyle to 2 at design time for non-resizable forms and remember to run Calvin's utility. A Projecthook should take care of this.

2. Change all my SCX's to form classes. Of course that means all forms designed with a Dataenvironment would need to be redesigned. I think I will skip this option.

A PITA to deal with # 1 but not insurmountable.


>>Hi Jim.
>>
>>>I'll work on a simple repro and submit it to Connect.
>>
>>If I read http://blogs.msdn.com/calvin_hsia/archive/2007/04/27/fix-your-forms-to-paint-borders-correctly-under-vista-aero.aspx correctly, I don't think this can be fixed because it's a Vista rather than VFP issue now.
>
>I think Calvin is of opinion that he actually can fix it. He also writes:
>
>So your choices are:
>
>Open the Form as a table (It really is just a table) and manually put BorderStyle before DoCreate.
>Run the program below that fixes your SCX files by putting the BorderStyle property before the DoCreate
>Convert your SCX forms to VCX (Visual Classes), where the BorderStyle is set at window creation time. (Just choose File->Save As Class from the Form designer)
>Wait for the next release of VFP SP
>Run Vista without Aero
>Run your app as Admin
>
>
>The solution he probably has in mind is a different order of processing the properties found in the memofield.