>After a bit of tweaking that now works fine :)
>
>However, this is now spiralling out of control. They now want the whole row to be a different colour if a particular field is not empty (to say its complete). I'm worried that this will really slow down the grid, is there any other way of achieving this?
>
>I've been this way before with grids, before you know where you are, they have become complicated beasts.
>
>Would a third party grid control do this job faster & better?
>
>Regards

Robin,
Are we still talking about FoxyClasses EditGrid (I assume so:) ?
1) You could add the condition to the list of iif()s < bg >
2) You might edit the init of grid (a simple way would be to copy&paste original class code to your subclassed grid and edit there - part you'd edit would be in the lines setting color expressions so little possibility you'd break the integrity of code)
3) After blindly saying these 2 options < g > and remembering your previous questions about added fore/backcoloring I took time to recheck class code :) What a relief class code already have the ammo (I should have thought the class code was already prepared for situations like these before:).

This is from init :

*..
  for each oColumn in .Columns
    with oColumn
	.DynamicBackColor = '(this.SetBackColor("'+.Controlsource+'"))'
	.DynamicForeColor = '(this.SetForeColor("'+.Controlsource+'"))'
    endwith
  endfor
*..

And if you check the SetBackColor, SetForeColor methods you'd see method code signatures are already setup to accept multiple parameters (honestly when I first designed them I put all those as reserves and currently only first one is used:)

This propagation to a method instead of multiple nested iif()s was the thing I'd suggest. You can edit the code in SetBackColor, SetForeColor methods and pass more than 1 parameter to it (as I see it's prepared for up to 11 parameters). To do that ie:

* Init of subclassed
dodefault()
local lcFieldToCheck
lcFieldToCheck = 'myTable.myField'
with this
  for each oColumn in .Columns
    with oColumn
	.DynamicBackColor = '(this.SetBackColor("'+;
                    .Controlsource+'","'+lcFieldToCheck+'"))'
	.DynamicForeColor = '(this.SetForeColor("'+;
                    .Controlsource+'","'+lcFieldToCheck+'"))'
    endwith
  endfor
endwith

* SetBackColor and SetForeColor (copy&paste class code for easy code change)
Lparameters tcControlSource,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10
With this
  Do case
&& You might use oldval() and isnull() as in code 
&& instead of empty() or fldstate() depending on your necessity
     case empty(eval(p1)) 
        return 0x00FFFF && Magenta back or forecolor as sample
*...

Now for slowing down, if your SetBackColor/ForeColor or similar color returning method is not complex it wouldn't have much impact on performance. Keep in mind Dynamic* properties are reevaluated only for 'visible' part of grid. That's if your grid has fewer rows/columns it'd update faster.

3rd party ? You mean a grid other than FoxyClasses' ? There are activex ones. I worked with MS activex grids (that come with VFP and V.Studio) and I'd say they're not worth the trouble and more if you're setting multiple cells which are not adjacent than they're slower. You don't just put Dynamic* expression but rather do painting on your own (and per cell if color doesn't apply to whole grid, whole column/row or a rectangular region). Maybe it was personal disability to do it but for me native grid outperforms them in functionality (yet there are 2 specific cases I use them in my own apps).
Cetin