>>>>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.
>
>This could be fine for my little 2 field screen, but isn't this a general problem. Picture the traditional customer form in edit mode. You're updating several fields (address, phone, etc.). On the last CHANGED field (FAX) you press the "skip to the next record" button without first pressing or . On returning to this record, my experiencince is that the FAX field (in which I did not press ), has NOT been updated although the other fields have.
>
>Is this normal. Am I missing some simple updating rule tht would get rid of this behavior.

Edit form should not have navigation buttons, or, if you use the same form, navigation buttons should be disabled during edit process. I believe this is traditional robust approach.

Edward Pikman
Independent Consultant