Fix your forms to paint borders correctly under Vista Aero

Apparently, the borders of some forms don’t get painted correctly on Windows Vista.

When executing a Fox Form, Fox asks Windows to create a window, then sets the BorderStyle of the window. Apparently, under Vista Aero (except as Administrator), the BorderStyle cannot be set after the Window has been created.

To reproduce the problem, start Visual FoxPro (I tried back to VFP7 (released summer 2001))

• File->New->Form
• In the property sheet, dbl-click BorderStyle to change it to 1 or 2
  • 0 = No border ( no problem, because there are no borders to draw)
  • 1 = Fixed Single
  • 2 = Fixed Dialog
  • 3 = Sizable (Default) (no problem, because it’s the default)
• Hit Ctrl-E or click on the “!” in the toolbar to run the form. Give it a name
• Move the form around so that the borders or title bar will need to be repainted
• Result: The window behaves as if there is no border: it won’t get repainted.

Amazingly enough, run under Admin mode, and you’ll see the problem disappear. Perhaps a non-admin app changing the BorderStyle might be a security risk: An app might be able to grab a window handle from another process and impersonate a Credentials screen or something.

When Fox runs a form, it reads the Properties and sets them in the order encountered. For a Form, the “DoCreate” pseudo property means to create the window. The BorderStyle happens to be written after the DoCreate, so the BorderStyle setting is ignored

The properties look like this before the fix:

Top = 0

Left = 0

Height = 250

Width = 375

DoCreate = .T.

BorderStyle = 1

Caption = "Form1"

Name = "Form1"

.

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

See also

• Foxpro Menu items, combo boxes not refreshing selected item under Aero in Vista
• Add a manifest to control your application Vista UAC behavior

Program starts below (and works in VFP7 too)

CLEAR ALL

CLEAR

FixDir(CURDIR()) && Call recursive program with current directory

*Recursive program to fix all forms found in cPath and subdirectories

* Fix Vista Aero Border painting by changinge DoCreate and BorderStyle order

PROCEDURE FixDir(cPath) && Fix all forms in directory cPath and subdirectories

LOCAL n,aFiles[1],cPath,i,j,cTemp,nBorderStyle,nDoCreate,aProps[1],nLines,nIndex

n=ADIR(aFiles,cPath+"*.scx") && look in current dir for all form files (.SCX)

FOR i = 1 TO n

?cPath+aFiles[i,1]

USE (cPath+aFiles[i,1]) ALIAS SCX && open the form as a table

SCAN FOR !EMPTY(Properties) AND ATC("DoCreate",Properties)>0 && locate the Properties

?Properties

nLines = ALINES(aProps,Properties) && Create an array of all the lines in the Properties

nDoCreate=0

nBorderStyle=0

FOR j = 1 TO nLines && Loop through and record the array indices of DoCreate and BorderStyle

?j,aProps[j]

DO CASE

CASE ATC("DoCreate",aProps[j])>0

nDoCreate=j

CASE ATC("BorderStyle",aProps[j])>0

nBorderStyle=j

ENDCASE

ENDFOR

IF nDoCreate > 0 AND nDoCreate < nBorderStyle && If DoCreate precedes BorderStyle, insert BorderStyle before

cTemp=""

FOR nIndex = 1 TO nLines && now emit the properties in the desired order

DO CASE

CASE nIndex = nDoCreate

cTemp=cTemp+aProps[nBorderStyle]+CHR(13)+CHR(10)

cTemp=cTemp+aProps[nDoCreate]+CHR(13)+CHR(10)

CASE nIndex = nBorderStyle

* do nothing: already added

OTHERWISE

cTemp=cTemp+aProps[nIndex]+CHR(13)+CHR(10)

ENDCASE

ENDFOR

REPLACE Properties WITH cTemp && and update

?properties

ENDIF

ENDSCAN

USE IN SCX && close the file

ENDFOR

n=ADIR(aFiles,cPath+"*.*","D") && Get any subdirs

FOR i = 1 TO n

IF ATC("D",aFiles[i,5])>0 AND aFiles[i,1] != "."

FixDir(cPath+aFiles[i,1]+"\") && recur

ENDIF

ENDFOR

RETURN

</end of program>

Comments

• Anonymous
  April 27, 2007
  I've modified the code: instead of swapping the DoCreate and the BorderStyle, it now inserts the BorderStyle before the DoCreate. It might make a subtle difference, although I don't know of any cases where it would.

• Anonymous
  April 28, 2007
  Calvin, Your continued contributions to the VFP community are much appreciated.  Keep up the great work!

• Anonymous
  April 29, 2007
  Hi Calvin, thank you very much for another insight into the inner workings of VFP. I'd like to add that your fix can be called from a project hook class' BeforeBuild event. Unfortunately it's not as useful for a professional VFP user. Most of us are using Visual SourceSafe with VFP. So most forms are checked in at build time and thus are read only (removing the read only attribute is not really an option). As the ProjectHook class has no BeforeCheckIn event I have no clue how to automate running your code before check in. Any idea? TIA, Markus

• Anonymous
  April 29, 2007
  Unfortunately this fix does not work - at least under VFP 8. Mostly (but not always) the borders are correctly painted on creation, but if a form is opened over the top, or the form moved over the edge of the screen and back, corruptions occur. The properties of one my forms that does not work (after Calvin's fix) are: Height = 396 Width = 314 BorderStyle = 2 DoCreate = .T. ShowTips = .T. AutoCenter = .T. Caption = "Letter Generator" ControlBox = .F. Closable = .F. MaxButton = .F. MinButton = .F. WindowType = 1 Name = "LETTER" I have tried moving other properties before the DoCreate, but without success. Interestingly, running as administrator does correct the problem. Another workaround I have just tried is to set HalfHeightCaption = .T., which gives a Windows 2000 look, but does seem to avoid the corruptions. A final problem affecting VFP applications is with fonts corrupting. I understand from Rick Strahl that this is due to the ClearType setting which is now default in Vista. Are there likely to be any solutions to this?

• Anonymous
  April 30, 2007
  Dominic: I tried creating a form with exactly the same properties as you specify in VFP8, and it repro’s the Aero problem as expected. I run the fix in my code above to put the BorderStyle before the DoCreate, and the problem goes away. Keep in mind that every time VFP rewrites the form from any modification, the fix above needs to be applied. If you can still repro the problem, can you provide the exact repro steps. Thanks

• Anonymous
  April 30, 2007
  Markus: Perhaps in your beforeBuild event you can run code that turns off the readonly attrib, applies the fix. The AfterBuild event can be used to clean up. You could even make/restore a backup copy in these events.

• Anonymous
  April 30, 2007
  Calvin, Thank you for these set of fixes!

• Anonymous
  May 01, 2007
  Above is an image of an inner form (from the C++ project below) before and after I dragged it a little

• Anonymous
  August 10, 2007
  Here are some of the links that I often visit regarding VFP9 SP2 and Sedna. The official Microsoft Visual...

• Anonymous
  September 04, 2007
  The comment has been removed

• Anonymous
  October 28, 2007
  How can I enabled the Aero Glass effect to a  VFP program that's built as a SDI? In other words, this program uses the main VFP screen at runtime. VFP ignores the Aero Glass effect. Can it be enabled in this instance?

• Anonymous
  October 31, 2007
  We've figured out the Vista border issue (we think). We couldn't reproduce it here, but Jim Slater noted

• Anonymous
  September 17, 2008
  The Border problem exists also with Border Style = 3. I fix the program be amended and all was well.

• Anonymous
  December 17, 2008
  The comment has been removed

• Anonymous
  June 12, 2009
  ヒマだょ…誰かかまってぉ…会って遊んだりできる人募集！とりあえずメール下さい☆　uau-love@docomo.ne.jp