Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Problems with fairly straightforward form requirements.
Message
From
19/07/1999 21:53:47
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Title:
Problems with fairly straightforward form requirements.
Miscellaneous
Thread ID:
00243408
Message ID:
00243408
Views:
54
I have a very straightforward work order entry form that consists of a combo box to choose the work order number of the work order I'm working on, and a few edit boxes bound to work order fields that may be edited by the user.

But I just cannot figure out which properties and/or methods to customize in order to meet the exact behavior I'd like to see in the form. I've banged at it awhile now, (a week), so maybe someone out there can help me.

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.

(2) I open the table in pessimistic record buffering mode. The buffering gives me the ability to allow the user to UNDO record changes before they are committed. This pretty much works great.
A user can change a field, move to another field, change it, etc. and for the most part, if nothing is done to cause the record pointer to change, my UNDO button (which does a TABLEREVERT), does the right thing. 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).

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.

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

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

TIA to anyone who has had the patience to read all of this and respond on any of the issues.
"The Iron Fish: The water is cold...but the fish don't mind"
...Jay Jenks, boyhood chum
Next
Reply
Map
View

Click here to load this message in the networking platform