>>THIS.VALUE = davidtable.workordernumber &&or whatever the field is
>>THIS.REFRESH
>
>I'll try this. I have shied away from using the .value property up to this point because the documentation clearly states the it contains the 'type' of the value being displayed. By it's name, I would expect it to contain a value equal to the value displayed and of the same type (even though what is displayed is always a text string). Is this true?

It contains the value. By setting the value you can change the datatype of the control. I think I have found the phrase that threw you. From VFP6 Help:"When a control source is set, the Value property setting of a control is the data type of the variable or field referenced by the ControlSource property."

>>>(2) I open the table in pessimistic record buffering mode.
>>
>>Do yourself a favour and use optimistic buffering. This will prevent a user leaving for lunch while editing a record and causing a huge headache for everyone. See John's buffering article (follow the hyperlink) on how to use optimistic buffering.
>
>I understand the user-frienliness of optimistic buffering. But right now I'm looking for something that's programmer friendly. It's simpler to deny write access until a record is released than to address the issues of resolving whose copy gets priority when two or more have changed it. For now, I'd rather keep it simple until actual use proves the pessimistic approach to be too limiting.

You can implement optimistic buffering in a very simple way that doesn't check for collision. I think it is called "last one wins". Quite simply if more than 1 person is editing a record, the last one to save has his changes written. This may or may not work in your situation.


>>>[Invisible TABLEUPDATE problem ...
>>
>>Put a SET STEP ON on the lostfocus of one of the controls that is causing the behaviour some of your code must be doing this.
>
>I'll try that. I think I can eliminate all of my code except for the refresh that occurs when the value is changed. (Which I've tried once already). But I'll play with the debugger a little more using your suggestion to see if I can catch it. (Does the form refresh default code cause a table update?)

Nope. If you are using buffering you must issue a tableupdate to save changes.

>>>(3) [Rambling stuff which basically says, I'd like to use the 'Incremental Search' feature with the combobox but it's behavior is not realiable. Entering a value that's in the combobox list does not always cause that value to be selected even if the keys are entered well within the double-click timeout.]
>
>Is the incremental search known to have flakey behavior? Do people avoid it or program their own equivalent by hand?

I have never seen flakey behaviour with incremental search in a combo. If you are using a combo style rather than a "drop down list" you will need to get the list to drop down before you do an incremental search.

>>Also you might want to choose a different way of navigating to a new record since you may go beyond the capibility of the combo if you have too many records.
>
>You lost me here. It's true that the table is not very long now (about 200 records) but this could change. Not sure what you mean by 'beyond the capability of the combo'. I actually started out using a one-column grid (per a suggestion from Jim Booth), but the combo or list seemed like a simpler mechanism for what I wanted to do. Also, I thought it might have been the grid that was causing my row buffering setting to be ignored. (item 4 below)

I have seen references over the last few years that you shouldn't go much over 500-1000 records for a combo. Try a search on "combo max" to look at the threads.