Hi David. I will give some of this a shot. Comments will be below each relevant section. Hopefully others will give their two cents also.

>Basically, I have the combobox set up to display and choose the work order number which is the key upon which the table cursor is ordered. Various edit controls are bound to fields of the work order record. I have modified the 'Interactive' and 'Programmatic' change event methods to refresh the form so that changing the work order number combo box causes fields of the newly selected record to be displayed.
>
>Nominally, this all works. But the rub is in the details. Here are the issues.
>
>(1) When the form opens on the screen, I want the combo box to immediately show the value of the work order number in the first record of table. Although the first record is always selected on initialization, the combo box is blank and can only be filled by opening up the related list and selecting a value. I have tried modifying both the form and the combo box init methods to set properties that seem like they'd control this behavior...but to no avail.

In the init of the combo put the following code to ensure the combo appears with the inital value of the table.

THIS.VALUE = davidtable.workordernumber &&or whatever the field is
THIS.REFRESH

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

>However, if I change a field, then simply change the focus to the work order number field (the field that selects which record I'm viewing), this action seems to trigger an internal TABLEUPDATE even though the simple act of setting the focus to the 'selector' field does not change the value of the selector (and therefore the implied table pointer). Of course when TABLEUPDATE occurs (my assumption), the UNDO button doesn't work (observed fact).

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.

>Is there some implicit functionality in the underlying focus changing logic that causes the automatic TABLEUPDATE, and if yes, can I defeat it. My goal is to only update the table record if the user changes the value of the selected work order.

It must be your code doing this.

>(3) I would like the user to be able to modify the record selector (work order number) using the conventional list navigation keys and also by entering the number manually. In neither case do I actually want the value of the key field to be altered (I think this implies I should use style 2 combobox). I have tried using the automated list search where VFP autocollates as one types the digits of the work order number. But this sometimes works and sometimes doesn't...at best, it's 'flakey'. I suspect there's weird interactions between the double-click timeout and whether the record I'm searching for is in a local cash or must be fetched from the server. Is VFP flakey by nature with this feature, or could I be doing something wrong. I'm loath to mess with the double click time out since it applies to mouse use in general (am I the only person who things tying the search key input timeout to the mouse double click timeout is TOTALLY STUPID!)

You lost me on this one. Don't put the controlsource of the combo to the field if you don't want the combo to change the value.

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.

>(4) As I said, I use pessimistic record buffering. Yet, when I have multiple users (on different computers, of course), multiple instances of the form behave as if the table is table buffered. Ie., records seem to remain locked by the first toucher until that user exits the form. I recall reading somewhere in the documentation that this can happen under certain circumstances, but I'll be damned if I can remember where I read about how to mitigate the problem. I suspect this may be related to problem (1), but whatever it is, any help in discovering how to operate in a true record buffered mode would be appreciated.

Are you issuing a LOCK command or are you letting VFP put the lock on the record? If you manuall lock a record you will have to UNLOCK it as well.