>
I don't like to have custom methods of grid itself. You know, grid is too unstable thing, it loses its settings too often.
<

Wow... you bascially invalidated every commercial framework on the market, especially Visual MaxFrame, which has loads of subclassed Grids.

I don't see how having a direct subclass of the Grid Class, with custom methods is affected by the Grids instability..... When you talk about the issues with columns, and not being able to subclass those, sure, that is a pain... However, the rationale you give here does not follow...... And by the way, grids by themselves do not lose their settings... It is usually the result of tinkering with the Recordsource Property....


>
Moreover, I don't like to subclass grid. I prefer to define grid as part of form or container. Form/container itself could be a class, but this is different story.
<

OK. so you would create a container class, and then add a Grid to that class, and then in turn, add the container to a form... That is fine. Then you should add a custom method to the container, and communicate with that interface, instead of the Grid Interfacce... Would you agree with that????

>In regard to column issue. I didn't read other messages in this thread, so I will make some assumptions. Basically, grid settings includes as main part of it, setting of controlsources for each column, therefore having some object (custom) on form that will re-code these controlsources will do it. I have some classes to accomodate the cases when user make free-style queries (i mean random fields, criteria etc) and the result goes to the same grid.
>

Sounds way more complicated than it needs to be Ed. However, it is consistient with your other "Fox 2.x'ish code-centric" approaches....