>>>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.

Thanks for the advice. I'll try the columns(1). The reason I don't use the default behaviour is that after the setfocus() I also do a Save and New which sets the focus to a form field & away from the grid. Saves the user doing a Alt+N.

I like the argument for using views. My program will be widely (I hope) distributed with no access to onsite support. Users will tend to be novice and therefore crashes and table corruptions are a real risk (and nightmare).

Sarah