Vis FoxPro vs Access arrgghhh!
I know these discussions of "my product is better than yours" can be really tiresome. That's not what's on my mind. As a Visual FoxPro expert and an Access complete neophite, naturally there are things I miss (and nothing much is familiar), BUT I'm also seeing very sweet things in Access's design that I like a lot.
Here is the thing I'm finding hard to do in Access that I'm missing most and rather surprised about:
I would almost never want to create a form in which a change to a field is immediately posted to its table. I'll virtually always want the effects of changes buffered on the record level. I went through the last 17 pages of forum topics and found one that discusses putting a Save button on the form, and using acCmdSaveRecord or acUndo to manage whether modifications to fields are posted to the table. Fine so far.
The next degree of sophistication that I want in Access is that the Save and Cancel buttons for the current record do not appear or are visible but disabled unless/until a bound field has been altered by the user. In VFP you simply put controls on the form that already have some code in their InteractiveChange Method (I know event names and other terms are arbitrarily and unnecessarily different between MS products) that sets a flag and enables or makes visible the Save and Cancel buttons, and disables the form Exit button. One also uses code to detect that the flag is set (or that the Save/Cancel buttons are visible/enabled) before allowing record movement. The user sees a msgbox with something like "Please Save or Cancel before closing/moving, blah, blah."
Then I looked at the Access textbox control and found that it has an On Change Event. So it appears that this kind of behaviour (the spelling of 'behavior' here is a polite concession to you non-Yanks) CAN be accomplished. But for every control, one needs to insert a chunk of Event code that calls a sub that manages the buttons. And for every such form, one needs to put in the standard subprocedures that are called (a) by the bound controls and (b) bu the record movement controls. The difference is that without subclassing, one must do this manually and not forget or slip up on a single control or the integrity of the form is lost. Seems pretty hard.
Whew! Sorry for this long post (my first). Here are my questions: Is this kind of management of the Save and Cancel impractical in Access? If I upgrade to Access 2002 from Access 2000 will there be some magic inheritance feature that makes this easier? Does no one care but me about this kind of user interaction and data safeguarding? Is there an easy way to create custom controls that already have the On Change event code attached to them?
Ok, have at it! TIA for your views.
I know these discussions of "my product is better than yours" can be really tiresome. That's not what's on my mind. As a Visual FoxPro expert and an Access complete neophite, naturally there are things I miss (and nothing much is familiar), BUT I'm also seeing very sweet things in Access's design that I like a lot.
Here is the thing I'm finding hard to do in Access that I'm missing most and rather surprised about:
I would almost never want to create a form in which a change to a field is immediately posted to its table. I'll virtually always want the effects of changes buffered on the record level. I went through the last 17 pages of forum topics and found one that discusses putting a Save button on the form, and using acCmdSaveRecord or acUndo to manage whether modifications to fields are posted to the table. Fine so far.
The next degree of sophistication that I want in Access is that the Save and Cancel buttons for the current record do not appear or are visible but disabled unless/until a bound field has been altered by the user. In VFP you simply put controls on the form that already have some code in their InteractiveChange Method (I know event names and other terms are arbitrarily and unnecessarily different between MS products) that sets a flag and enables or makes visible the Save and Cancel buttons, and disables the form Exit button. One also uses code to detect that the flag is set (or that the Save/Cancel buttons are visible/enabled) before allowing record movement. The user sees a msgbox with something like "Please Save or Cancel before closing/moving, blah, blah."
Then I looked at the Access textbox control and found that it has an On Change Event. So it appears that this kind of behaviour (the spelling of 'behavior' here is a polite concession to you non-Yanks) CAN be accomplished. But for every control, one needs to insert a chunk of Event code that calls a sub that manages the buttons. And for every such form, one needs to put in the standard subprocedures that are called (a) by the bound controls and (b) bu the record movement controls. The difference is that without subclassing, one must do this manually and not forget or slip up on a single control or the integrity of the form is lost. Seems pretty hard.
Whew! Sorry for this long post (my first). Here are my questions: Is this kind of management of the Save and Cancel impractical in Access? If I upgrade to Access 2002 from Access 2000 will there be some magic inheritance feature that makes this easier? Does no one care but me about this kind of user interaction and data safeguarding? Is there an easy way to create custom controls that already have the On Change event code attached to them?
Ok, have at it! TIA for your views.
