>>>>Is there a way to make my "sub-classed" grid column unfurls with my own
>>>>"sub-classed" textbox?
>>>
>>>Welcome to the club. I've complained of the same thing at least twice
>>>this year, and I don't remember any useful response.
>>
>>Well, what you _can_ do is use the ASELOBJ() function on the grid, iterate
>>through the columns, remove the default textbox, and add your custom
>>textbox.
>
>We're talking something else here. All this stuff is possible from
>within the form designer, but - grid is the only class where you can't
>set different defaults when you add new elements. Come to think of it -
>all the container classes behave like that. I've had an optiongroup
>class with defined two option buttons; these two buttons were not of the
>base class. When I've changed the ButtonCount to three, the form
>designer added the third button - but the button was different from the
>first two: it belonged to the base class.
>
>Now is there any way to change this behavior? I'll probably become
>everyone's nuisance here, but: is there any way to change defaults, and
>is there a way to do it programmatically. The above process may be
>performed - like when you have a grid without record source, add one,
>and it gets the default columns. Then you go thru the columns and
>replace headers, delete textboxes and add your controls. Fine - but what
>about the overhead? I plan for a class of dynamic grids, which will be
>built at runtime. Do I have to run this code upon every instance of it,
>or can I have a different grid class, with _my_ default headers and
>textboxes?

It seems that you know all of the solutions that I would be able to suggest, and I believe that this is the only way. I agree, modifying the grid at runtime is seemingly unnecessary overhead, but can it be that much? In the situations where I have replaced grid members at runtime, I did not notice a performance hit at all. Placing code in the init of the grid to do the replacement as opposed to design time is also advantageous in that it allows the grid to build itself from its datasource and resize its columns accordingly. Because a grid builds itself from the inside out, the columnwidths and recordsources are already assigned by the time the grid.init runs, and you can replace the headers and controls while retaining the grid attributes automatically built at runtime.

The one complaint I do have is that we cannot store a subclassed header. We must create a custom header programmatically, which means we must do it in a stored procedure.