Form OnClose vs. subform BeforeUpdate validation: the showdown
in [Help]
|
From: downwitch on 16 Jul 2010 16:39 Hi folks, thought I'd throw one more post on the heap of complicated form/subform event woes here at CDMA. My setup is this: I have an unbound form which contains a bound continuous subform. Everything's staging (until a user clicks save, at which point bound and unbound data are fired off toward a persisted back end), so dumping it when closing the form is automatic. The subform does some validating in the Form_BeforeUpdate event, and prevents the user from leaving the record if there is invalid data. Even though it's a temp table, it's useful to do it while the user is on a given record because the user's already there. Problem is, when the main form gets closed, or its unbound record gets cancelled, or whatever, there is no longer any need to validate that data. And Access, alas, fires the BeforeUpdate event on the subform before it "knows" that the main form is closing, i.e. it goes something like this: user chooses to dump --> subf BeforeUpdate fires, validates --> mainf Close events occur So in a situation where the user has entered invalid data and just decides to kill the record--not that uncommon, after all--at least one message pops up saying there's invalid data, and then even if I choose to continue with the close, Access throws its own message warning the user that the data in the record can't be saved--meaning the subform's unupdated record--and asking if it's still ok to close. I understand why the subform needs to store data before closing the main form, and therefore why the events go in the order they do, but there does not seem to be any exposed event even telling the subform that a close/cancel state is coming from above. Or am I missing something? The short version: Can I somehow know the main form is closing while still in a dirty subform, thus allowing me to choose to validate or not? Crossing my fingers that someone out there has worked through this before. Thanks in advance for any insight.
From: Marshall Barton on 16 Jul 2010 23:38 downwitch wrote: >Hi folks, thought I'd throw one more post on the heap of complicated >form/subform event woes here at CDMA. > >My setup is this: I have an unbound form which contains a bound >continuous subform. Everything's staging (until a user clicks save, at >which point bound and unbound data are fired off toward a persisted >back end), so dumping it when closing the form is automatic. > >The subform does some validating in the Form_BeforeUpdate event, and >prevents the user from leaving the record if there is invalid data. >Even though it's a temp table, it's useful to do it while the user is >on a given record because the user's already there. > >Problem is, when the main form gets closed, or its unbound record gets >cancelled, or whatever, there is no longer any need to validate that >data. And Access, alas, fires the BeforeUpdate event on the subform >before it "knows" that the main form is closing, i.e. it goes >something like this: >user chooses to dump --> subf BeforeUpdate fires, validates --> mainf >Close events occur > >So in a situation where the user has entered invalid data and just >decides to kill the record--not that uncommon, after all--at least one >message pops up saying there's invalid data, and then even if I choose >to continue with the close, Access throws its own message warning the >user that the data in the record can't be saved--meaning the subform's >unupdated record--and asking if it's still ok to close. > >I understand why the subform needs to store data before closing the >main form, and therefore why the events go in the order they do, but >there does not seem to be any exposed event even telling the subform >that a close/cancel state is coming from above. Or am I missing >something? > >The short version: Can I somehow know the main form is closing while >still in a dirty subform, thus allowing me to choose to validate or >not? What you're missing is that it doesn't matter if the main form is closing or not. As soon as the focus moves out of the subform, whether it's back to the main form or to another subform, the dirty subform must try to save its data. That is necessary to preserve data integrity. I think you will need to use a module variable to keep track of what's going on in the subform. Set the variable to False in the subform's Current event and set it to True in the save button's Click event, before doing whatever you do to save the data. Then the form's BeforeUpdate event can test the variable, if it's False undo the record, else proceed. -- Marsh
From: downwitch on 18 Jul 2010 12:04 Thanks for the reply. I understand that the conflict isn't occurring specifically "because of" a close event on the main form. In fact, *no* event taking place in the main form is known to the subform before it tries to save its record. My validation is not built into the subform's underlying table, so the data "can save" to the Access table first, regardless of "validity" or of what is to come next, but logically speaking, if I am abandoning the process in any way-- cancelling entry, closing the form without saving, etc.--no validation should occur. If the validation doesn't matter to the table, the data can save for an instant before the form closed and blew away the temp record anyway. (Not sure that was clear before. Is it now? Heh.) Current won't work because a) the record isn't dirty at that point, and more importantly b) the user's intention--to save or to cancel--is still unknown at that point. A module variable won't work either, because it can't get "reset" in time to stop the validation. If a user clicks a cancel button, e.g., the BeforeUpdate event *still fires* before the button's event does. Can't win. I am increasingly leaning toward moving away from the set of subform events that fire first. Then the problem becomes, how do I leave those events alone, but still simulate a before-update and keep the subform from moving off its current record, in cases where I am not cancelling. It's a pretty maddening little seesaw. On Jul 16, 11:38 pm, Marshall Barton <marshbar...(a)wowway.com> wrote: > downwitch wrote: > >Hi folks, thought I'd throw one more post on the heap of complicated > >form/subform event woes here at CDMA. > > >My setup is this: I have an unbound form which contains a bound > >continuous subform. Everything's staging (until a user clicks save, at > >which point bound and unbound data are fired off toward a persisted > >back end), so dumping it when closing the form is automatic. > > >The subform does some validating in the Form_BeforeUpdate event, and > >prevents the user from leaving the record if there is invalid data. > >Even though it's a temp table, it's useful to do it while the user is > >on a given record because the user's already there. > > >Problem is, when the main form gets closed, or its unbound record gets > >cancelled, or whatever, there is no longer any need to validate that > >data. And Access, alas, fires the BeforeUpdate event on the subform > >before it "knows" that the main form is closing, i.e. it goes > >something like this: > >user chooses to dump --> subf BeforeUpdate fires, validates --> mainf > >Close events occur > > >So in a situation where the user has entered invalid data and just > >decides to kill the record--not that uncommon, after all--at least one > >message pops up saying there's invalid data, and then even if I choose > >to continue with the close, Access throws its own message warning the > >user that the data in the record can't be saved--meaning the subform's > >unupdated record--and asking if it's still ok to close. > > >I understand why the subform needs to store data before closing the > >main form, and therefore why the events go in the order they do, but > >there does not seem to be any exposed event even telling the subform > >that a close/cancel state is coming from above. Or am I missing > >something? > > >The short version: Can I somehow know the main form is closing while > >still in a dirty subform, thus allowing me to choose to validate or > >not? > > What you're missing is that it doesn't matter if the main > form is closing or not. As soon as the focus moves out of > the subform, whether it's back to the main form or to > another subform, the dirty subform must try to save its > data. That is necessary to preserve data integrity. > > I think you will need to use a module variable to keep track > of what's going on in the subform. Set the variable to > False in the subform's Current event and set it to True in > the save button's Click event, before doing whatever you do > to save the data. Then the form's BeforeUpdate event can > test the variable, if it's False undo the record, else > proceed. > > -- > Marsh
From: Marshall Barton on 18 Jul 2010 12:39 downwitch wrote: >Thanks for the reply. I understand that the conflict isn't occurring >specifically "because of" a close event on the main form. In fact, >*no* event taking place in the main form is known to the subform >before it tries to save its record. My validation is not built into >the subform's underlying table, so the data "can save" to the Access >table first, regardless of "validity" or of what is to come next, but >logically speaking, if I am abandoning the process in any way-- >cancelling entry, closing the form without saving, etc.--no validation >should occur. If the validation doesn't matter to the table, the data >can save for an instant before the form closed and blew away the temp >record anyway. (Not sure that was clear before. Is it now? Heh.) No it wasn't clear before and, no, it is not clear now. Nor is it clear why that matters to this discussion. > >Current won't work because a) the record isn't dirty at that point, >and more importantly b) the user's intention--to save or to cancel--is >still unknown at that point. A module variable won't work either, >because it can't get "reset" in time to stop the validation. That's why I said to reset the variable in the Current event. If the BeforeUpdate event is triggered while the variable is False, then your save button was not used and you can undo the record and exit. If the save button was used, the variable will be True so the validation can proceed and if it passes, the record can be saved (however you do that). > If a user >clicks a cancel button, e.g., the BeforeUpdate event *still fires* >before the button's event does. Can't win. For any of this to make sense, the save and cancel buttons must be on the subform. > >I am increasingly leaning toward moving away from the set of subform >events that fire first. Then the problem becomes, how do I leave those >events alone, but still simulate a before-update and keep the subform >from moving off its current record, in cases where I am not >cancelling. It's a pretty maddening little seesaw. The subform would have to be unbound for that to work, but then it could not be continuous. > >On Jul 16, 11:38�pm, Marshall Barton wrote: >> downwitch wrote: >> >Hi folks, thought I'd throw one more post on the heap of complicated >> >form/subform event woes here at CDMA. >> >> >My setup is this: I have an unbound form which contains a bound >> >continuous subform. Everything's staging (until a user clicks save, at >> >which point bound and unbound data are fired off toward a persisted >> >back end), so dumping it when closing the form is automatic. >> >> >The subform does some validating in the Form_BeforeUpdate event, and >> >prevents the user from leaving the record if there is invalid data. >> >Even though it's a temp table, it's useful to do it while the user is >> >on a given record because the user's already there. >> >> >Problem is, when the main form gets closed, or its unbound record gets >> >cancelled, or whatever, there is no longer any need to validate that >> >data. And Access, alas, fires the BeforeUpdate event on the subform >> >before it "knows" that the main form is closing, i.e. it goes >> >something like this: >> >user chooses to dump --> subf BeforeUpdate fires, validates --> mainf >> >Close events occur >> >> >So in a situation where the user has entered invalid data and just >> >decides to kill the record--not that uncommon, after all--at least one >> >message pops up saying there's invalid data, and then even if I choose >> >to continue with the close, Access throws its own message warning the >> >user that the data in the record can't be saved--meaning the subform's >> >unupdated record--and asking if it's still ok to close. >> >> >I understand why the subform needs to store data before closing the >> >main form, and therefore why the events go in the order they do, but >> >there does not seem to be any exposed event even telling the subform >> >that a close/cancel state is coming from above. Or am I missing >> >something? >> >> >The short version: Can I somehow know the main form is closing while >> >still in a dirty subform, thus allowing me to choose to validate or >> >not? >> >> What you're missing is that it doesn't matter if the main >> form is closing or not. �As soon as the focus moves out of >> the subform, whether it's back to the main form or to >> another subform, the dirty subform must try to save its >> data. �That is necessary to preserve data integrity. >> >> I think you will need to use a module variable to keep track >> of what's going on in the subform. �Set the variable to >> False in the subform's Current event and set it to True in >> the save button's Click event, before doing whatever you do >> to save the data. �Then the form's BeforeUpdate event can >> test the variable, if it's False undo the record, else >> proceed. -- Marsh
From: downwitch on 18 Jul 2010 22:39
Well fair enough. I shall try to spell it out as simply as I can, because I can assure you that it is more than clear enough to me. The bound subform must be bound to be continuous, as you point out. Multiple records, but they are temp records, so "saving" them is meaningless, until the master record gets saved. It's a grid of detail data hanging off a master record, the end. So while it might make technical sense to throw variables and save/cancel buttons into the subform, it makes zero sense from a logical/business perspective: every saved record in the subform is meaningless if the user cancels the whole process. Current is a meaningless subform event in this case: only dirt matters. It's a data-entry setup, so you want to catch bad entries at the moment of entry. Not to mention that continuous/datasheet scenarios are always a bit misleading, as they only ever point to one record anyway, and that one record with the bad data is the one that matters. But all validation of an entered field (or multiple fields, as there are rules that combine fields) is *meaningless*, once again, if the user cancels the master record. So yes, there are all sorts of ways I could "force" the user to validate each subform record with a click. This would be dumb, however, and in a classic data-entry setup, every keystroke (let alone a mouse click, ugh) counts. I want to validate the subform following the user's field-by-field or record-by-record entry, *unless* the user wants to cancel the whole shebang, in which case I want to validate nothing. But I can't get out to cancel the main without validating the sub. If that doesn't make sense, sorry, I can't put it any more plainly. On Jul 18, 12:39 pm, Marshall Barton <marshbar...(a)wowway.com> wrote: > downwitch wrote: > >Thanks for the reply. I understand that the conflict isn't occurring > >specifically "because of" a close event on the main form. In fact, > >*no* event taking place in the main form is known to the subform > >before it tries to save its record. My validation is not built into > >the subform's underlying table, so the data "can save" to the Access > >table first, regardless of "validity" or of what is to come next, but > >logically speaking, if I am abandoning the process in any way-- > >cancelling entry, closing the form without saving, etc.--no validation > >should occur. If the validation doesn't matter to the table, the data > >can save for an instant before the form closed and blew away the temp > >record anyway. (Not sure that was clear before. Is it now? Heh.) > > No it wasn't clear before and, no, it is not clear now. > Nor is it clear why that matters to this discussion. > > > > >Current won't work because a) the record isn't dirty at that point, > >and more importantly b) the user's intention--to save or to cancel--is > >still unknown at that point. A module variable won't work either, > >because it can't get "reset" in time to stop the validation. > > That's why I said to reset the variable in the Current > event. If the BeforeUpdate event is triggered while the > variable is False, then your save button was not used and > you can undo the record and exit. If the save button was > used, the variable will be True so the validation can > proceed and if it passes, the record can be saved (however > you do that). > > > If a user > >clicks a cancel button, e.g., the BeforeUpdate event *still fires* > >before the button's event does. Can't win. > > For any of this to make sense, the save and cancel buttons > must be on the subform. > > > > >I am increasingly leaning toward moving away from the set of subform > >events that fire first. Then the problem becomes, how do I leave those > >events alone, but still simulate a before-update and keep the subform > >from moving off its current record, in cases where I am not > >cancelling. It's a pretty maddening little seesaw. > > The subform would have to be unbound for that to work, but > then it could not be continuous. > > > > > > > > >On Jul 16, 11:38 pm, Marshall Barton wrote: > >> downwitch wrote: > >> >Hi folks, thought I'd throw one more post on the heap of complicated > >> >form/subform event woes here at CDMA. > > >> >My setup is this: I have an unbound form which contains a bound > >> >continuous subform. Everything's staging (until a user clicks save, at > >> >which point bound and unbound data are fired off toward a persisted > >> >back end), so dumping it when closing the form is automatic. > > >> >The subform does some validating in the Form_BeforeUpdate event, and > >> >prevents the user from leaving the record if there is invalid data. > >> >Even though it's a temp table, it's useful to do it while the user is > >> >on a given record because the user's already there. > > >> >Problem is, when the main form gets closed, or its unbound record gets > >> >cancelled, or whatever, there is no longer any need to validate that > >> >data. And Access, alas, fires the BeforeUpdate event on the subform > >> >before it "knows" that the main form is closing, i.e. it goes > >> >something like this: > >> >user chooses to dump --> subf BeforeUpdate fires, validates --> mainf > >> >Close events occur > > >> >So in a situation where the user has entered invalid data and just > >> >decides to kill the record--not that uncommon, after all--at least one > >> >message pops up saying there's invalid data, and then even if I choose > >> >to continue with the close, Access throws its own message warning the > >> >user that the data in the record can't be saved--meaning the subform's > >> >unupdated record--and asking if it's still ok to close. > > >> >I understand why the subform needs to store data before closing the > >> >main form, and therefore why the events go in the order they do, but > >> >there does not seem to be any exposed event even telling the subform > >> >that a close/cancel state is coming from above. Or am I missing > >> >something? > > >> >The short version: Can I somehow know the main form is closing while > >> >still in a dirty subform, thus allowing me to choose to validate or > >> >not? > > >> What you're missing is that it doesn't matter if the main > >> form is closing or not. As soon as the focus moves out of > >> the subform, whether it's back to the main form or to > >> another subform, the dirty subform must try to save its > >> data. That is necessary to preserve data integrity. > > >> I think you will need to use a module variable to keep track > >> of what's going on in the subform. Set the variable to > >> False in the subform's Current event and set it to True in > >> the save button's Click event, before doing whatever you do > >> to save the data. Then the form's BeforeUpdate event can > >> test the variable, if it's False undo the record, else > >> proceed. > > -- > Marsh |