Sylvain...

My point was simply that when you set a color attribute, the operating system controls the interface to the video card, which then maintains that color or other attribute. In this event, VFP is not cycling to maintain a given appearance; the only cycling taking place is low-level clock cycles, and those I'm not worrying about eating up. It's only explicitly cycling (via a timer or other method) that I'm concerned about.

Just one of those nice old tricks from a simpler environment that would be helpful to still have around... :)

Scott

>The hardware doesn't know how to flash a component. There will allways be a timer somewhere that will need to refresh the display.
>
>Yes, a timer may slow a little bit the process, but not by much. You have to make a compromise somewhere, either you build your code as fast as possible without using any visual clue at a chance that the user think that the application is frozen and hit the dreaded CTRL-ALT-DEL keys or you impact the performance a little bit to let the user know that the computer isn't dead.
>
>Personally, if I guess that a certain part of the application will take longuer than 5 seconds, I will put up a thermometer.
>
>>I was concerned that a timer would affect performance, especially when I'm doing some serious querying that's grabbing a lot of system resources. Either the queries would be slowed down by the timer, or the timer would be stuttering because of the lack of resources that VFP will devote to it vs. the query. In either event, it would be better to simply tell the hardware that this is a flashing component than to repeatedly tell it to flash.
>>
>>Am I incorrect in this assumption about performance?