>>There are few basic things here (they are not mandatory, but can help; it does not mean that other way will not work but it can give troubles).
>>1) It's a good idea to use short-cut menu instead of combo.
>>2) If #1 is not accepatable (e.g. because of client's wishes) then combo should be populated manually (Add(List)Item) and be bound on character field (I know abound BoundTo property but it still better to have character)
>
>A shortcut menu is definitely not an option here ... have to use a combo. In order to add manually (using AddItem), doesn't the RowSource have to be an array? I didn't think that method was for table RowSources. I don't remember if my combo was bound to character or numeric, but I think it's numeric. Why is it better to bind to a character field? (I'm not doubting you, I just want some insight!)

VFP combos don't linke to be bound on integers. In VFP3 it was required to unbind combo with integer. In VFP5 BoundTo property was introduced, so you can bind, and it works safely for stand-alone combo. If it's in grid it may still give problems (again they might be overcome, but character binding will save you time and nerves considerably).

>>4) Obviously, when we speak about grids, combos etc, there are absolutely should not be any temp relationships between tables.
>
>Hmmm ... I'll have to disagree with you on this one. If you have child-columns being displayed, you need to have a relationship.
>

No, temp relationships is not a requirement and have potential danger of extra pointer moving. Grid has highly intensive (in regard to pointer moving) code behind.

>One of the biggest problems, that I see, is that you *cannot*, for any reason, mess with record pointers in any of the tables involved in the grid. I don't know why, I only know that it screws things up big time!! I'd love to understand this stuff better. It's very frustrating to me because before VFP came along, I knew 2.6 inside and out ... the cause and effect of every little command I used. Not so in VFP!!!

IMHO, good VFP design should carry completely separated data and interface, i.e. users set pointers when it really necessary (retrieve data to interface and store interface values to data). Between these two points actual pointer location should not make any impact on application flow.