>>> The underlying definition of the grid with the custom stuff should not go away regardless of how I change the .RecordSource or .ControlSource properties.
>
>Unfortunately, changing RecordSource is basically equivalent to momentarily setting ColumnCount to 0. All data bindings are lost, and all columns in the grid will revert to their default controls.
>
>You can dynamically build a smart grid by subclassing controls (a textbox, or checkbox, or whatever), and then do something like:
>

>.Visible=.F.
>.RecordSource=""  && quick revert
>.ColumnCount=(whatever the new number will be)
>For i=1 to .ColumnCount
>  with .Columns(i)
>    .RemoveObject(Text1)
>    ).AddObject("Text1","MySubclassedTextBox", [maybe some unique init stuff here])
>     *etc.  You can do the same with headers
>   endwith
>EndFor
>.RecordSource="WhatEver"
>.Visible=.T.
>

>
>By subclassing the controls that you place in the grid (or by even subclassing the columns), you provide a mechanism to dynamically control which methods and events will be active with any given control. For example, in the Init method of MySubclassedTextBox, you can pass to it, and store, the names of routines to call if a click, doubleclick, or rightclick event happens. Makes your code a bit obscure but sure adds flexibility.

The grid is already dynamically built but is just doesn't include having to "readd" what should already be there. But 'tis another VFP quirk to work around.

Thanks,
Steve