>>Is there any reason that you didn't want to add/edit/delete directly in the grid?
>>
>>Joe
>>
>
>I'm trying for some consistancy in my interface. Although this particular screen has only 2 fields, some will have 20 and would be unworkable as a grid.
>In this case, is there some reason I should do it in the grid?
>Bob
>-----------------------------------------------------------------------------
>
>>>I’m new to the graphical interface, and have built a simple VFP 5.0a screen with a 2 column, readonly grid populated from a table, and a pair of text fields with their datasource coming from the same two fields of the table being displayed in the grid.
>>>
>>>I navigate with my VCR toolbar, or my special navigation keys set up in the base form’s keypress method. I’m using optimistic row buffering. The purpose of the form is add/edit/delete. My scheme is select with the navigation keys, (the grid hilighting should move) and do my editing in the two text boxes.
>>>
>>>I’m having some problems. If after making my change, I move to the next record with my navigation keys without first presing enter, I loose my change. In addition, I can’t seem to get the row highliting in the grid to move as I sit on a text box and press my next() or previous() navigation key. Without a mouse (some of my data entry users) the idea of scrolling through a grid and then going to the textboxes seems a little awkward. I think I’m missing some concepts here.
>>>
>>>1) Can I leave either textbox with my navigation keys without loosing my update?
>>>2) How should I link the grid highliting to my navigation while in a textbox?
>>>3) Should I bypass the text boxes, set my grid’s readonly to .f., and do my add/edit/delete directly in the grid?
>>>
>>>Bob

Try to sell your users following idea:
1. Add one more grid column and put 'Edit' button over there.
2. When user clicks on the button, new modal edit form appears, where user will perform entries,saves,etc.
Of course, it's simplification, but it works Ok for non-critical interface.