Use Button on Main form to ALSO control the subform

[Mahoney]

Hi Everyone,

I have a main form and a subform, I created a button to close the form and popup a msgbox with vbYesNoCancel if i need to save. All is working well, but when changes are made to the subform and close the form from the button, it is not working properly. When I choose not to save it saves, and also it is not responding to the yes and cancel buttons also,

many thanks in advance

 

[Banana]

Out of curiosity, is the main form unbound?

As for saving when you don't want to save it, that's not because of the button but rather by design- As soon you leave the subform and into the main form, Access silently saves the subform. By same principle, when you enter subform from main form, Access silently saves it (reasonable as Access need to have it written in order to be able to relate the new subform record to the form's records).

 

[boblarson]

You can't do that on a main form to control the save of the subform because when you click the button, the data has already been saved in the subform because it saves automatically when you move to the main form. And, when you move to the subform from the main form, the main form's data has already saved.

So, you basically would need to run two DELETE queries (one for the subform data and one for the main form data) to delete the records that have been created, if you want to cancel the whole thing.

 

[Mahoney]

many thanks guys,

therefore it is useless to have a button to close the form and ask if i want to save, as saving happens automatically
thanks

 

[Banana]

Well, a button to close the form is fine. It's just the saving part that's a bit useless.

But to be clear, if you want to do a validation before saving the record, BeforeUpdate event should be used for that so you have control over whether a given record makes the cut or not.

 

[boblarson]

many thanks guys,

therefore it is useless to have a button to close the form and ask if i want to save, as saving happens automatically
thanks

Well, that all depends on how you look at it. From a user perspective, they don't need to know about the inner workings so you could still have the button and if they close without clicking the button you run some delete queries to delete the data that was entered. It is all up to how you want to set up the UI.

 

[Banana]

Well, that all depends on how you look at it. From a user perspective, they don't need to know about the inner workings so you could still have the button and if they close without clicking the button you run some delete queries to delete the data that was entered. It is all up to how you want to set up the UI.

While I do agree that users doesn't have to know about inner working, I should clarify that if users are "trained" to expect wrong things, there'll be headaches down the road. Having a save button probably would be one of those thing ("I didn't save it but it get saved anyway!").

Thus, it's in my best interest to make sure users expect the same behavior as Access would behave, even if they don't completely understand why.

 

[boblarson]

While I do agree that users doesn't have to know about inner working, I should clarify that if users are "trained" to expect wrong things, there'll be headaches down the road. Having a save button probably would be one of those thing ("I didn't save it but it get saved anyway!").

Thus, it's in my best interest to make sure users expect the same behavior as Access would behave, even if they don't completely understand why.

But that is assuming you didn't code for closing without clicking the button. I suggested that you could set it so that if the button wasn't clicked you could discard the changes by running a couple of delete queries in the background. What's wrong with that? Nothing, in my mind. You are not constrained by what Access does if there are ways around it. I don't see anything wrong with making the program act like what users would expect instead of resigning yourself to moving to something just because Access "does it that way."

So, like I said - it all depends on what the desired UI would be. It is the programmer/developer's job to figure out how to make it work. The users need not be concerned with the fact that Access automatically saves records when you leave.

 

[Banana]

Well, my concern stem from two things:

1) the Murphy's Law- if user can find something to break it, they probably will and quite creatively so.

2) divergence in expectations- if user see and expect something else when program is doing one thing, they will request for something that is even more incompatible with the current design.

From my POV, it's easier to train users to click "Undo" button that execute my custom code to perform delete queries where appropriate than to provide a "Save" button and silently delete in event of non-click and when the users see half-saved record by mistake or whatever, they only have themselves to blame and that's easily fixed by clicking that Undo button I gave them.

They don't even have to know specifically when Access saves records silently; even a fuzzy statement such "sometime it does, sometimes it doesn't" is good enough for them and they'll make use of the Undo button even on a unsaved record (assuming I've coded for such case) and get exactly the result they expect.

It may be programmer's job to provide the requested feature, but it does no good to provide feature based on misunderstanding of what the program does.

Ah, that's just my $.02. Not worth much, I'm afraid.

 

[boblarson]

I guess we'll just agree that we disagree on this then eh?

 

[Banana]

Yes, but to be clear, your idea is not without its merits. I can certainly understand why we should be responsible for designing application exactly to the users' expectation and not to program's expectation.