Hi!

See comments below...

>>
>>For what you need this functionality??? MANY things for grid could be done quite another way than just subclassing columns. I worked on the grid that do very complex processing for ALL columns in grid, but nether worked so slow even for grids with 200 columns.
>
>I know, I even change all the headers with a custom class

I did it too ;) And for each header fixed the caption, so when caption is cut, it is displayed as "My Long Ca..." - the same way as in Outlook, to hint user that caption is not displayed completely. This was quite a slow thing, until I optimized it. After optimizing, it worked without significant delay even for 200 columns. There are alsways a way to optimize something for speed <g>.

>
>Need it to HighLight the current row. (property of the grid: HighLightCurrentRow)
>In the event that the DynamicBackColor is changed by program, I have to 'intercept' the assignment and change it,
>eg grid.Columns(3).DynamicBackColor = 'rgb(255,0,0)'
>is changed by the assigmethod (in case grid.HighLightCurrentRow = TRUE) to
>[iif( recno(thisalias) == this.CurrentRecno, rgb(255,255,64), rgb(255,0,0))]
>
>Simply put: I need an event to know that the DynamicBackColor of any column has changed

I know 2 approaches:

1. Set a timer that will check if Dynamic* changed compare to the old value. If changed, just fix it and refresh a grid. Store old value in the new property for each column added by AddProperty. If you have custom header class, better store it there, so no additional time reqired to create property for each column.

2. I remember very rare situations when you need to change the DynamicBackColor. Just a suggestion for better solution on the level of design:
Instead of direct change, create a method on the grid class called "ChangeDynamicBackColor". Call it with 2 parameters - expression and the column, when column is 0 - this expression is for all columns. Then in that method in the class fix the expression to highlight a row and also set the DynamicBackColor for column.
The above approach is PUREly from the OOP - do not change any member value in object directly. In VFP there is Assign method for that. When no way - create a custom method and call it. Before inventing the "property" and method for setting its value, OOP theory recommended to use method for each member-field for setting its value. Here this approach is exactly that <g>.
Of course, this will require to document grid class and make a warning for other developers to use that method instead of direct assignment to DynamicBackColor.

>>
>>I can also look to code and tell what could be improved and how to improve speed.
>
>the rest of the code is fine, it's just the addition of 86 columns and the deletion of the 'old' 86 columns, preserving all the properties of the 'old' columns, like ColumnOrder, and the like
>

Right. Header object replacing by custom class probably is much more quick than replacing the column, because for column there are a LOT of additional actions to do inside VFP engine during replacing the column - update properties, create controls inside of the column etc. etc. You can probably suppress most of these things by setting _VFP.AutoYield to .F. to do not process any supplement events during column replacing, but I do not beleive it will help much.