>>>>
>>>>Hi again, Sarah.
>>>>
>>>>You don't happen to have Form.LockScreen = .T., because that might prevent the action you want to take. Probably not. You might also try to requery() the source-view if indeed it is a view you have as a source.
>>>>
>>>>Holding my thumbs
>>>
>>>Lockscreen is new to 5? It was .f. The child of the grid is a table, not a view.
>>
>>Too bad, I strongly suggest views in that kind of situation...and any other, for that matter. Avoid direct use of tables; I don't have a single action performed directly at a table in several big applications (3.0 & 5.0). Its safer, easier to update/revert changes and, after all, what the views are for.
>>Apart from that, something like

grid.columns(1).SetFocus()

should do it, as Cetin explained in his posting earlier.
>
>Danijel,
>Come on, she could use a table with a grid w/o no fear. We were doing it before views too, with browse :) I'm still doing it directly with tables (even they're not small apps) and buffering is not only for views :) I don't think a table or a view is the real problem here. I suspect there is underlying code in valid, lostfocus, keypress of control, in keypress of form (keypreview = .t.) etc preventing default action.
>Cetin

Most definently true, my friend.
However, since the arrival of views I chose to let my tables in peace, and did all my modifications on views, letting tables either accept or reject those modifications. In doing so, I rest assured that tables only recieve valid data by update from views after user is done modifying the data. One of the things I don't like about modifying tables is those unexpected crashes, often performed by unexperienced users, that leave tables with incomplete data. It has resulted in a corrupt table a few times, and one corrupt table is one too many.