For generall purposes its fine.

I run into 2 problems with that behaviour

1. my errorhandler reports wrong class
2. the point where I trap into that was a SETALL('DYNAMICBACKCOLOR',..,'_column') command.

To me the biggest problem is, that if I use not only one class in one object, I can not see the origins and can not use SETALL to change a specific group.

The problem with the caution in the help file will raise if VFP needs to reload code from the prg. This reload will be based on the class and classlibrary of the object. I have no idea what I need to do to force such a situation. May logic says that this will be bound to internal memory handling.
That means that it will produce some new hard to track errors. I stay without.

::) it's not to hard for me because I create my colmuns with ADDCLASS from .prg based column classes since decades. I also swap the header of those columns using something like:

.Column1.REMOVEOBJECT('Header')
.Column1.NEWOBJECT('Header2','myHeader','myprg')
.Column1.Header2.Name = 'Header1'

There was some hope to speed up that process but the old will work anyway.

Agnes

>>Hi Mark,
>>
>>You display column.Headerclass.
>>
>>what I mean is column.header1.class or column.class
>
>Here you go. I see that the Header1.Class property now says header, but the correct [desired] class is being used because my header click is firing for each header. I also get NO errors doing it this way.

>Column1 Name: Column1
>    .Class             : Column
>    .HeaderClass       : _Header
>    .HeaderClassLibrary: d:\apps\uicora\_gridmembers.prg
>    .Header1.Class     : Header
>    .Header1.ClassLib  : _gridmembers.fxp
>
>...snip...
>
>Column7 Name: Column7
>    .Class             : Column
>    .HeaderClass       : _Header
>    .HeaderClassLibrary: d:\apps\uicora\_gridmembers.prg
>    .Header1.Class     : Header
>    .Header1.ClassLib  : _gridmembers.fxp