>>>>>>>In my drag-and-drop grid, I am also having a problem with speed. I have cleaned out all of the "extraneous" stuff I can find from any relevant methods, and yet my grid is very slow to move from cell to cell.
>>>>>>>
>>>>>>>What areas typically cause a grid to slow down dramatically?
>>>>>>>
>>>>>>>Paul
>>>>>>
>>>>>>The things that slow down a grid the most seem to be any sort of dynamic... property and making the grid large in terms of surface area. For example if to the right of the last column you have a lot of empty space, this seems to slow down the grid (I don't know how fox managed this one.) My resolution is 1152x864 and if I make a grid (or a browse) maximized, it is many times slower than a smaller version of the same thing.
>>>>>>
>>>>>>HTH,
>>>>>>Peter
>>>>>
>>>>>I wouldn't agree that dynamic properties will slow down a grid. Actually, VFP is smart enough (I believe) to check just visible area of recordsource (6-8 rows) and doesn't go beyond.
>>>>
>>>>True it only redraws the visible space, but it still calls the dynamic properties alot. And it calls the dynamic properties more than you might think. I found that the DyanmicCurrentControl property is called for each line that is visible (when sparse is true) because if Dyn...Control returns a container or a button that cell needs to be empty if not currently on that cell or the container or button if on that cell. I like the dynamic properties, I just try to use them as little as possible to minimize the performance hit. ;-)
>>>>
>>>>Peter
>>>
>>>If you agree that is called for visible part only, then what are you worrying about? Do you want to say that firing couple lines of code 6-7 times will visibly slow down the process? Of course, it's possible to write some extremely bulky code which will do the job, but ... it's our responsibility as developers to find better solutions.
>>
>>
>>After taking Peter's advice, and removing completely my dynamicbackcolor properties, I saw a performance increase of about 50 percent. This is the only dynamic property I was using, and it is a very simple value:
>>this.setall("DynamicBackColor","=iif(this.value = 'BLACKOUT',rgb(255,255,255),SCHED_HD.BACK_COLOR)","Column")
>>
>>Based on this I would have to say the underlying code behine the dynamic properties is not very efficient. I also have to say, however, that it isn't the only culprit.
>>
>>Paul
>
>Excuse me, Paul, but I see a problem with your 'simple' code. The problem is that you use 'This.Value' as 'dynamic identifier', and this is not consistent solution. Basically, dynamic properties should be evaluated based on Grid.Recordsource field values, e.g.
>cLine1="IIF(field5="+this.tag+",16711680,8421376)"
>this.SetAll("DynamicBackColor",cLine1,"Column")
>Needless to say that you will also get slight improvement using direct backcolor values instead of RGB().
>All this about one thing, check your code before blaming the product.

Well thanks for the friendly help.
Now, before you come down on me too hard, let me explain a little further:
1. This code has replaced several other methods of trying to set cell by cell colors, including statements which access the table.field value directly for each cell. Each cell has to column has to check a different field for it's background color, because certain cells are blacked out. I went to the call which checks "this.value" because it was a quicker way to try to do check different methods than changing 240 columns 1 at a time or even programatically.
2. I have also tried it using both RGB() and direct backcolor values and seen no significant differences.

I like VFP as much as anyone else. I think it is a wonderful product with a tremendous amount of power. Unfortunately I have a very tricky application which I am having trouble to get to perform well, so I came to the UT as it has been an excellent source of information in the past. If you have any suggestions, I do appreciate them very much, however I don't appreciate being slammed because I have run across a problem.

Thank you
Paul Moon