>>As I try to recall all the editable fields in the DOS "grids", they are mostly "pick lists", validation routines (which can be very complex), and calculations (gross/qty-unit). I don't see where I would need a combo box (but I haven't used enough to see their value or use).
>>
>>Is this the kind of thing you do in your grids..?
>
>Used to have a combo in a grid, four jobs ago, back in VFP5 to 6, and didn't really like it. Combo in a grid sometimes needs some taming (sometimes even a checkbox does), so I won't put it there if I can help it. I'd rather pop up a little form with just one grid which can then be searched, would have incremental search under my control (i.e. whatever user types won't expire after _dblclick seconds) and such a form may even have additional buttons. IMO, much more functional than a combo. Combo is practical when you have no more than a few dozen entries, but already in the hundreds, it's unwieldy for the user. The user may not type fast enough for incremental search to work, the entry they're looking for may be misspelled... I rather allow a partial entry in the regular textbox, then look it up (using all possible tricks - SQL with LIKE operator among them) and pop up a search grid.
>
>I've had such data entry grids on several projects in the last four years, and they all worked great. Sometimes I had the layout that MikeY describes (data entry above, navigation in the grid below), sometimes the one I mentioned (narrow navig. grid on the left), sometimes I had a huge entry grid which took most of the form's area (because such was the nature of the data - had one huge sparse table that needed a lot of adding and editing). In all of these, I managed to get away with nothing but textboxes (often subclassed), checkboxes and sometimes a commandbutton. Actually, had one container as well :).

Just FYI, that is not the design I'm describing. I think it was Mike Sue-Ping you're referring to.