Jim,

As usual, very helpful advice. Thanks. Some responses follow..

In response to my question about a control's value property...

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

I take this to mean that even if the value of the bound column is of numeric type, the value property contains the string of numerals that represent the number. This would imply that the following:

this.value = MyVariableHavingNumericType

Would (hopefully) generate an error but at the very least have unexpected results.

If true, this would imply that I typically would need to use type conversion if I want to use or modify the value property of a control bound to an object having numeric type.

>This has nothing to do with user friendliness, it has to do with simplicity and control. Pessimistic buffering does magic stuff, optimistic buffering does.

Well, on purely simplistic grounds, "it's mine til I say you can have it" is pretty simplistic. Didn't know about the magic stuff that by its existence eliminates the simplicity. I'm sorry to hear that the automatic locking/unlocking mechanisms have unpredictable/poorly defined behavior, since I was looking to that to save me some development time.

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

That sounds like a good idea. (Though the problem is that simply switching focus to the record selector ... without changing its value ... appears to be causing the update). Table buffering to eliminate auto commit and auto unlocking and then still do the record by record thing manually so I don't tie up records too long sounds like the right thing. (of course, if I go optimistic, this becomes moot, but in general, the table locking approach seems like the key here...thanks.)

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

Well, since you write books on the subject, I'll do what you do. I'm trying to visualize what you are talking about. It sounds like you have an edit box in addition to a drop down list type combo box which means (with my naive understanding) that the singular edit box and the combo's edit box are both visible... that seems a little confusing. Is there a way to eliminate the combo's edit box from view?

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

Thanks. will try.

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

Would love to. I'm as much a control freak as anyone though as you know from previous exchanges, I'm trying to save time by utilizing certain advertised features. Alas, the lack of complete documentation on automatic (as well as manually controlled) behaviors has caused me to trip over the unseen dangers. (There just aint no free lunch...sigh!) You may have seen my comments in the last few days questioning the default behavior inherited from VFP baseclass methods. David Frankenback was able to give me some references to third party doc that might help but he also said, "try it...see what happens"... That's not the answer I want to hear about a product that is so highly touted by industry professionals. I think you have to admit, a thourough technical specification for VFP is sorely lacking. The expository nature of the developers manual is helpful for general approaches but let's face it, when it's time to get down to the nitty gritty details, a resource like UT is not only very useful...it's a downright necessity.

It's worth every penny of the full benefits membership!