VERSIONS: All
Subject: Form repaint extremely slow
Date: 6 May 2005
BY: LUC KUMPS
We had developed an application with many forms. It has been in use for many months, running fine. A new computer arrived, we installed
the application, it ran fine except for a few forms that ran very slow. Some taking a full minute to load. After a lot of experimenting we found out
that the problem was caused by the presence of edit fields that were not bound to a table, i.e. undefined or calculated by a formula.
When these fields were visible, even moving to another record in a table, by clicking on it, would take more than a second. When another
Windows application window was moved over one or more of these fields, the form repaint would take several seconds. While playing around
with a Task Manager window, moving it over the Paradox window, I noticed that "I/O other" was increasing with 44 every time I moved the Task
Manager window out of such an edit field. Moving the complete Paradox window to position the edit field outside the visible area would turn the
application back into 'normal' speed.
In an attempt to find out where "I/O other" was coming from, I used Filemon from www.sysinternals.com . No luck!
Then I used http://www.rohitab.com/apimonitor/ , logged File I/O and found the reason: the slow forms had been developed on a system
on which Paradox was installed on the D: drive. Every such an edit field needs to be repainted, the style sheet gets read about 15 (!!!) times. On this
particular system, D: corresponded to a DVD drive. With 10 such edit fields on the form, the small I/O timeouts cumulated in a BIG slowdown of
the complete form... Apparently, on this particular system, the I/O driver of the DVD drive introduced small delays whenever an application tried
to access a file on the DVD drive.
I used a hex editor to replace D: by C: and the form was as fast as it has always been.
I wonder how many applications out there appear slow because Paradox is looking for a style sheet on a network or DVD drive... If you ever
developed a form on a system with
- using the default style sheet, OR
- using a style sheet which is not present on the system on which the form is executed, e.g. because you're running it with Paradox Runtime,
your forms are loosing quite some time trying to look for a missing style sheet.
If you want to get a quick list of the style sheets in your forms, you can use the Windows "find" command from a command line window,
executed in the directory containing your FSL files, e.g.
find /I ".FT" *.fsl > out.txt
Here's the code I used to make all forms point to the same stylesheet...
stDirName is the name of directory containing the FSL files to be modified. If "lgIncludeSubDirs" is set to true, the subdirectories are handled
as well...
I wonder how many zillions of style sheets Paradox Runtime is trying to open endlessly around the world each day. Unfortunately, one can't
set the style sheet to an empty string...
method SetStyleSheetOneDir(stDirName string)
var
f form
fs FileSystem
ts TextStream
st string
stStyleSheet string
endVar
stStyleSheet = "C:\paradox\style.ft"
while fs.findNext(DirName+"*.fsl")
try
f.load(stDirName+fs.name())
f.SetStyleSheet(stStyleSheet)
st = f.GetStyleSheet()
if (st.upper()<>stStyleSheet.upper()) then
MsgInfo("Style Sheet not set for "+fs.name(), "Current style sheet="+f.GetStyleSheet())
return
endif
f.save()
f.close()
onfail
errorshow()
MsgInfo("FORM FAILURE", stDirName+fs.Name())
f.close()
endtry
endWhile
; Now handle subdirs
if lgIncludeSubdirs then
while fs.findNext(stDirName+"*.*")
st = fs.name()
if isDir(stDirName+fs.name()) and st.Substr(1)<>"." then
SetStyleSheetOneDir(stDirName+fs.name()+"\\")
endif
endwhile
endif
endMethod