I have some TPanel and other components on a form that I change aspects of, such as
visibility, position or height according to things that are happening. One of my
routines is doing things like this:

MyPanel.Top := 0;
MyPanel.Visible := true;
if Something then
 MyPanel.Visible := false;
else
 MyPanel.Top := 100;

Now, since that might be called many times, the code is changing things like
visible to one value, and then changing it back. How much work is done "then and
there" in these things? That is, what is the CPU Cycle cost of how this is being
done now?

Should I instead be writing it like this:

nTop := 0;
bVisible := true;
if Something then
 bVisible := false;
else
 nTop := 100;

 if MyPanel.Top <> nTop then
   MyPanel.Top := nTop;
 if MyPanel.Visible <> bVisible then
   MyPanel.Visible := bVisible;

This way does nothing if there is nothing to change. I recall being told when
working on GEM and the original Mac that it was better to check for a change and
not do it than to update the display because the cost of the update was many
thousands of CPU cycles times the comparison.

Thoughts?
   
/Matthew Jones/

I think you'll find that the framework typically only changes field values in property "setters" if the new value doesn't equal the existing value. This is pretty much standard practice for framework / component developers. A quick check of the framework source will confirm. Given this, I wouldn't worry about it on your side too much.  

Thanks. I do though set the values to both true and false in the same sequence, so
that may be guaranteeing a change. I think I should adopt the better approach to be
safe.

/Matthew Jones/

Matthew,

<< This way does nothing if there is nothing to change. I recall being told
when working on GEM and the original Mac that it was better to check for a
change and not do it than to update the display because the cost of the
update was many thousands of CPU cycles times the comparison. >>

I would stick with this approach.  While the toggling of the visibility may
not add much overhead, it's always best to err on the side of caution,
especially with browsers on some mobile devices.

Tim Young
Elevate Software
www.elevatesoft.com