>>>>Hi Matt... you are right, Larry's code works and I am using Larry's it...
>>>>thanks Larry..
>>>>
>>>>>>1. Why does your app generate so many blank/deleted records?
>>>>>>2. Why don't you want to PACK?
>>>>>>3. Are you using table buffering?
>>>>
>>>>I am coding a way the users can edit the COMBO BOX on their FORM. Should I have used a VIEW instead of a GRID? I am using a table and in a network environment and I did not want to PACK. If I use TABLE BUFFERING, then the users will have to SAVE/ABORT. I am tring to make EDITABLE COMBO BOX (a GRID) easy to use. If the users click on the ADD button, then they will get an APPEND BLANK or a RECALL from the deleted record. What do you think? thanks rob
>>>
>>>Matt, one more COMBO BOX, eh. Don't tell him about your arrays. It will work OK, but too complicated.
>>
>>I am interested in Matt's arrays...thanks..rob
>
>LOL @ Ed. Aren't COMBO BOXES fun????
>
>Actually rob, he's right. I'm using an array for a specific purpose of functionality, but it's kludgey as hell. Ed proposed a much simpler solution on the last thread regarding combo boxes. Go look it up.
>
>What do you mean by 'editable combo box'. If you wish to add items to the rowsource then define the combo as a combobox. If the entry isn't from the list, then add a record to the source table/cursor. If you want to 'edit' the value that's in the combo, that's a different matter. And you keep inter-changing GRID/COMBOBOX, I still can't follow what you're trying to do.
>
>What's wrong with save/revert? It's like giving the user a bottle of white out. Could you imagine a world without white out? Remember, you can use row buffering OR table buffering.
>
>Lastly, when's the last time you talked to your users? At least by your description, the form sounds a little busy. Get their input.
>
>HTH
>
>Matt

I am using a GRID to make changes to the table that my COMBO BOX uses as it's
source....