Hi Cetin/Sam,

I've been experiencing a similar problem. I have an application which changes the color of the grid lines depending on a status of the record. There are 8 statuses, so the grid lines can have up to 8 different colors. On my machine ( 128MB RAM ) everything works fine, but on my customers machine which has much less RAM, the grid sometimes doesn't show any lines, even though there are records to show. I'll move my SETALL code to the INIT and see what happens. I currently have the SETALL code in my ACTIVATE method.

Regards,
Gavin...

>>In a custom GRID class I have code that changes the colour of the grid depending on the deleted status of the record and also highlights the current record. This is achieved using setall dynamicbackcolor command in the grid refresh method:
>>
>>

>>thisform.nCurRec=recno(this.recordsource)
>>
>>this.SetAll("dynamicbackcolor",;
>>   "iif(recno() = thisform.nCurRec, ;
>>       iif(dele(),RGB(192,192,128),this.rowHighlightColor), ;
>>       iif(dele(),RGB(197,165,173),RGB(255,255,255)))", ;
>>    "Column")
>>

>>
>>When a form with a grid based on this class is active for a long time, it becomes apparent that RAM is being progressively consumed until it exhausts the physical RAM and starts disk swapping. I checked this by adding a textbox that displays the value of sys(1016) as the grid is refreshed, and watched the unused physical memory in the Windows System Monitor.
>>
>>Removing the grid coloring code resolves the problem. Anyone know why this is happenning.
>
>

---

Sam,
>Just move the code to init. It's unnecessary to call a function to set a property n times. That's the reason for extra consume. Also as I see rowHighLightColor I can say already your grid is subclassed. So good :) Move custom nCurrec property from form to grid which would make your grid class form independent.
>Cetin