>>Having a very bad time trying to figure this one. I have a screen with 40 buttons. I redefine them using the PROMPT 'xyz' clause. All was well until a certain version of the program when the redraws began to go rather slowly.
>>
>> Funny thing is, it's much less of a problem under 24 or 32 bit screen color densities. Just the opposite of what I'd expect. Also, when FPW 2.6 is first loaded, that part of the program runs very quickly, at leat two times, then on the 3rd pass and beyond, slowly.
>>
>> I'm running this under W95. Looks like some bizzare windows caching/memory problem and I have no clue how to work around this. The rest of the program runs ok, just this one screen acting up. Plenty of memory in the box (32 Meg) and a Matrox Millenium SVGA card.
>>
>> Is this a documented issue, or what?
>
>Have you tried using different vidoe drivers to see if that helps any? For something weird like this the first thing I'd try is using the standard Win95 SVGA video driver. If the problem stills occurs with the std. driver then I'd look at whats in memory, possible a tsr that maybe blocks out mem space that FP tries to grab once its been running long enough to chew up resources. HTH

Hello:

You said that you are painting 40 buttons that you redifine using PROMPT 'xyz'. Probably the speed problem resides on where are you getting the variables for the buttons or how you are getting them, a good idea will be TRACING your application's CODE, to find out where it's taking a longer time to execute, and then you can fix the problem, what it's really weird is that you are getting more performance with a better resolution, but belive me, 40 buttons should not slow down your app, particulary I have a screen that I use as a Calendar kind of thing which contains 44 buttons and I have no problem at all.

Bye.