Form OnClose vs. subform BeforeUpdate validation: the showdown
in [Help]
|
From: Marshall Barton on 19 Jul 2010 00:42 Sheesh, I missed where you said the subform was bound to a temp table. Sorry for wasting your time. The only way I can see you avoiding the record validation in the subform is if all edits/additions are done in unbound controls, positioned to look like the current record. But then it gets tricky finding a time/place to validate, save and move the data to a real subform record. Maybe the subform's Current event and the main form's save button?? Not sure it would be worth all that trouble though. -- Marsh downwitch wrote: >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.
From: downwitch on 19 Jul 2010 10:09 It's all good--I appreciate whatever help I can get on this. One more thing to think about: the validation is not of the is-this- data-ok-to-save variety, but rather of the no-that-doesn't-match-the- rules variety. There is nothing on the temp table itself that would stop the saving of the invalid data, if the UI rules didn't interfere. So letting the controls be bound doesn't cause the problem--it's the "decision" to validate or not. On Jul 19, 12:42 am, Marshall Barton <marshbar...(a)wowway.com> wrote: > Sheesh, I missed where you said the subform was bound to a > temp table. Sorry for wasting your time. > > The only way I can see you avoiding the record validation in > the subform is if all edits/additions are done in unbound > controls, positioned to look like the current record. But > then it gets tricky finding a time/place to validate, save > and move the data to a real subform record. Maybe the > subform's Current event and the main form's save button?? > Not sure it would be worth all that trouble though. > -- > Marsh > > > > downwitch wrote: > >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.
From: Marshall Barton on 19 Jul 2010 13:13 So, with a better understanding of what you are trying to do, we're back to your original question of how to not validate when the focus moves out of the subform. Clearly, the validation code can not be in the subform's Before (or After) Update event because that will be triggered automatically. You could try doing it in the save button for all the saved, but not validated, records in the temp table. The subform's AfterUpdate event may need to maintain a collection of the key for each temp table record that was saved during the session so the save button could retrieve and validate those records without wasting time on records that were already in the real table and not changed. If a subform record fails the validation checks, you could make that record the subform's current record, set the focus back to the subform and exit the save procedure. so the user could try to fix the record. At least this way, closing the main form will leave the temp table to just die on the vine. -- Marsh downwitch wrote: >One more thing to think about: the validation is not of the is-this- >data-ok-to-save variety, but rather of the no-that-doesn't-match-the- >rules variety. There is nothing on the temp table itself that would >stop the saving of the invalid data, if the UI rules didn't interfere. >So letting the controls be bound doesn't cause the problem--it's the >"decision" to validate or not. > >On Jul 19, 12:42�am, Marshall Barton wrote: >> The only way I can see you avoiding the record validation in >> the subform is if all edits/additions are done in unbound >> controls, positioned to look like the current record. �But >> then it gets tricky finding a time/place to validate, save >> and move the data to a real subform record. �Maybe the >> subform's Current event and the main form's save button?? >> Not sure it would be worth all that trouble though. >> >> >> downwitch wrote: >> >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.
From: downwitch on 19 Jul 2010 13:39 Yes, I thought about this direction as a good possibility. It's a little more cumbersome from the coding and logic standpoint--why loop through post facto when you could just watch in realtime--but I agree, none of the more logical approaches seem to work when it comes time to cancel. I think the subform current event only fires on a record change (and load of course, when everything's valid), so that is also a possibility, because I don't think a subform/main form focus shift moves the cursor. But again, waiting to get to record n+1 to check record n is a little counterintuitive, too. Validate automatically, but do an end-run around the Access event definition of automatic. Sigh. On Jul 19, 1:13 pm, Marshall Barton <marshbar...(a)wowway.com> wrote: > So, with a better understanding of what you are trying to > do, we're back to your original question of how to not > validate when the focus moves out of the subform. Clearly, > the validation code can not be in the subform's Before (or > After) Update event because that will be triggered > automatically. > > You could try doing it in the save button for all the saved, > but not validated, records in the temp table. The subform's > AfterUpdate event may need to maintain a collection of the > key for each temp table record that was saved during the > session so the save button could retrieve and validate those > records without wasting time on records that were already in > the real table and not changed. > > If a subform record fails the validation checks, you could > make that record the subform's current record, set the focus > back to the subform and exit the save procedure. so the user > could try to fix the record. > > At least this way, closing the main form will leave the temp > table to just die on the vine. > -- > Marsh > > > > downwitch wrote: > >One more thing to think about: the validation is not of the is-this- > >data-ok-to-save variety, but rather of the no-that-doesn't-match-the- > >rules variety. There is nothing on the temp table itself that would > >stop the saving of the invalid data, if the UI rules didn't interfere. > >So letting the controls be bound doesn't cause the problem--it's the > >"decision" to validate or not. > > >On Jul 19, 12:42 am, Marshall Barton wrote: > >> The only way I can see you avoiding the record validation in > >> the subform is if all edits/additions are done in unbound > >> controls, positioned to look like the current record. But > >> then it gets tricky finding a time/place to validate, save > >> and move the data to a real subform record. Maybe the > >> subform's Current event and the main form's save button?? > >> Not sure it would be worth all that trouble though. > > >> downwitch wrote: > >> >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.
From: Marshall Barton on 19 Jul 2010 14:44
I suggested using the subform's AfterUpdate event to log a record into the records to be validated Collection, because the Current event is too late to get to the changed record. If you want to validate a record immediately instead of waiting for the save button to do all the records, then the Current event seems like the only place you can do it and know that the subform still (or just got) the focus. This would minimize the number of entries in the collection, but make it messier because you would have to move back to the record to be validated and, If it passes, renavigate to the record the user just moved to. Either way it's unpleasant, but doable. -- Marsh downwitch wrote: >Yes, I thought about this direction as a good possibility. It's a >little more cumbersome from the coding and logic standpoint--why loop >through post facto when you could just watch in realtime--but I agree, >none of the more logical approaches seem to work when it comes time to >cancel. > >I think the subform current event only fires on a record change (and >load of course, when everything's valid), so that is also a >possibility, because I don't think a subform/main form focus shift >moves the cursor. But again, waiting to get to record n+1 to check >record n is a little counterintuitive, too. > >Validate automatically, but do an end-run around the Access event >definition of automatic. Sigh. > > >On Jul 19, 1:13�pm, Marshall Barton <marshbar...(a)wowway.com> wrote: >> So, with a better understanding of what you are trying to >> do, we're back to your original question of how to not >> validate when the focus moves out of the subform. �Clearly, >> the validation code can not be in the subform's Before (or >> After) Update event because that will be triggered >> automatically. >> >> You could try doing it in the save button for all the saved, >> but not validated, records in the temp table. �The subform's >> AfterUpdate event may need to maintain a collection of the >> key for each temp table record that was saved during the >> session so the save button could retrieve and validate those >> records without wasting time on records that were already in >> the real table and not changed. � >> >> If a subform record fails the validation checks, you could >> make that record the subform's current record, set the focus >> back to the subform and exit the save procedure. so the user >> could try to fix the record. >> >> At least this way, closing the main form will leave the temp >> table to just die on the vine. >> -- >> Marsh >> >> >> >> downwitch wrote: >> >One more thing to think about: the validation is not of the is-this- >> >data-ok-to-save variety, but rather of the no-that-doesn't-match-the- >> >rules variety. There is nothing on the temp table itself that would >> >stop the saving of the invalid data, if the UI rules didn't interfere. >> >So letting the controls be bound doesn't cause the problem--it's the >> >"decision" to validate or not. >> >> >On Jul 19, 12:42�am, Marshall Barton wrote: >> >> The only way I can see you avoiding the record validation in >> >> the subform is if all edits/additions are done in unbound >> >> controls, positioned to look like the current record. �But >> >> then it gets tricky finding a time/place to validate, save >> >> and move the data to a real subform record. �Maybe the >> >> subform's Current event and the main form's save button?? >> >> Not sure it would be worth all that trouble though. >> >> >> downwitch wrote: >> >> >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. |