Thanks for the reply, Edward. The table in question is not related to anything else (altho it is the child of another table, but that's intentional, that's why it's sometimes at EOF()). I don't see how another user moving the record pointer in this table could confuse the cbo ... it's a totally different data session at that point, why would that be a problem?

Also, that still doesn't answer my question about the table at EOF() ...

Bonnie

>>ComboBoxes will be my downfall yet!!! (And putting them as a control in a grid is even worse ... but that's a topic for another question). My question today is ... why does VFP *sometimes* (not always) mark a cbo as read-only if the RowSource table is at EOF()? When you try to click on it, the message at the bottom says it's read-only (and I didn't set that property.) However it then seems to be ok if I fire the drop-down via the keyboard instead of the mouse. Very bizarre behavior ... anyone have any insight in to how this is supposed to work?
>
>Basically, it's not a good idea to bind combo.rowsource on real table. The main disadvantage here is that a user moving mouse through the combo items will actually move record pointer in the table and this may inadvertently fire lot of other things (e.g. move pointers in related tables etc.), or in opposite case record pointer can be moved by another user/control action confusing the combo. It's more robust approach to base combos on cursors or fill them programmatically using Add(List)Item. Here, you will be safe knowing that the combo is working independently from other user's interactions.