>>>>>I've got a grid object in a container that only has 1 column in it.
>>>>>During program execution, I dynamically add columns to the grid with the AddObject method. Everything works fine, but I would like to allow the user to right-click or double-click >>>
>>>>Basically, you did everything right, but, unfortunately, it seems that grid gets corrupted somewhere in the middle. You know, grids used to be corrupted when there are too many on-fly re-buildings. IMO, the better way to have a solid grid is to create it in form designer as a first place and permannently base on read/write cursor. Then, whatever interface solutions you want to apply to this grid, it will be actually repopulating (DELETE/ZAP/INSERT) of this cursor.
>>>
>>>That's a good point. It certainly would save a lot of headaches when the Grid suddenly de-stabilizes for no known reason. A full rebuild with identical code fixes. Having some kind of data driven grid builder is an excellent idea. Do you think that control sources should only be placed programatically/run time not design time?.
>>
>>I don't want to say that this is the only way, but it's really safe way. However, I didn't mean that column.controlsources or grid.recordsources should be changed literally in run-time. Grid and their columns will be always based on the same cursor.fields, but record contents of this cursor might change.
>
>To be honest, this is a side question. There's a known bug in VFP 6.0 and grids. I don't remember specifically but it has to do with subclassing a form with a grid. If you use an alias for the table in the grid for some reason it tries to check the properies memos and returns an error that alias can not be found. That's why I was wondering if you preferred loading your control sources at run-time because that was the only fix we could come up with.

Actually, I was not aware of this particular problem, but I usually set grid.recordsource and column.controlsource in Grid.Init event, i.e. in run-time but just once.

Edward Pikman
Independent Consultant