David,

My comments on your reply to Evan.

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

The value contains the value of the bound column of the combo, it is always a character string.

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

This has nothing to do with user friendliness, it has to do with simplicity and control. Pessimistic buffering does magic stuff, optimistic buffering does not. If you want to wrestle with the magic stuff and figure out what it all is and how it works, then use pessimistic. Otherwise use optimistic and set your own locks.

>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?)

You are using Record buffering, whenever the record point moves, no matter why of where, there is an implicit tableupdate(). Use table buffering instead and control the user's ability to move to another record during an edit.

>Is the incremental search known to have flakey behavior? Do people avoid it or program their own equivalent by hand?

The incremental search of the combo works fine, if the combo is Dropdown List style. Using a dropdwon combo style VFP has the problem of figuring out igf the user is typing a new value or searching for an existing value. I use a textbox in combination with a dropdwown list combo in my forms. The textbox is disabled unless the suer is adding a new record to the file. If the user clicks the add button I enable the textbox and disable the combo.

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


A combo or list is good up to around 250-500 items, event that is too many for teh users though. The problem is what happens when your work order table has 100,000 work orders. Do you really want to wait for a combo to load 100,000 items? Do your users really want to scroll through 100,000 items looking for the oen they need?

How about a textbox that does the search in its valid event? Or a textbox that searches incrementally in its Keypress event?

>I count on automatic locking for everything and I count on moving the record pointer or explicit TABLEUPDATE's for updating and unlocking.

Counting on automatic anything truns over your control to the language. The main thrust of your query is "How do I get this stuff to work the way I want it to?" The asnwer is, "Stop letting VFP do whatever it wants and take control of the behaviors."