Hi Larry,

>>I did this exactly already. But, it seems like grid's child Init method executes before grid Init method itself. So, this approach doesn't work, because, as I said, all columns are defined in design-time, I mean, each column has ControlSource property set in design-time. Threfore, if my form received the table with different structure, one of column Init method failed, I assume. I traced in the debug: it successfully goes through Load method, then immediately stops. At this point Grid.Init method isn't even executed.
>>
>> Another solution is to temproraly delete these grids, add them again and place remove grid in one of the other form's control Init method. But this solution beats OOP conception, I think...
>>
>> What else can I try? BTW, this is probably not the case in our app, because the table will always have all required fields, but if this problem could be easily solved, I prefer to solve it...
>
>Is there any way for you to write in such a way as to have the controlsources set programmtically? For example, in the framework I use (VMP) there is a method called from thr Grid Init that sets the controlsources for all the columns. If you did it this way, then the Grid could return .F. and not initialize. If it passed your test, then the default behavior would be to call the new method.
>
>Just an idea.

Yes, this is an obvious idea, unfortunately, doesn't apply to my case. In the first grid I have ~35 columns, in the second ~60. Actually, it was not my application, I was assigned to make changes and repoint to our classes (it originally used VFP base navigation class - it's adominable :)). I did a lot of work, but today I found this problem during my test...


Anyway, I already discussed this problem with one of my colleague, and she assured me, that our table will always have the full structure, so this is not a real problem. However, it still may be a future problem, if we'll re-decide...

Thanks for your help.