- Local time
- Today, 18:22
- Joined
- Feb 28, 2001
- Messages
- 28,588
I'm pulling out what little hair I have left on this problem. Environment is VBA vers 6.5, Access v 11 SP3, WinXP SP3
Got a Form with a sub-form. Sub-form is locked because it is not updated from user action through that sub-form's controls - they are all locked. Some control buttons on the parent trigger a code sequence to do an .AddNew for the sub-form's recordset via VBA activities. The code does the .AddNew, fields get loaded in the record, .Update, .Close, and then I requery the sub-form.
The button that updates the sub-form saves the current record after it does some change auditing. I used the button wizard to build the skeleton and then edited the code to include the auditing. So I get to the point where I have done some VBA to update the sub-form and I requery the sub-form. The new record shows up fine.
Now I try to save the parent form with an updated status to match the last status code stored in the sub-form. (No, not storing a computed value... the sub-form new record holds the action status from the current status of the parent, not the other way around.) Once I requery the child record, essentially a detailed journal of action for the parent record, I want to also save anything updated on the parent. So I let the VBA code do what the button wizard created for saving records.
These two lines of code are driving me bonkers because they prove I don't understand the form Dirty flag. Before I enter this code, the form was dirty because I updated some data on the parent. SO I save it with...
When I put a breakpoint on the second line of code, i.e. after a call that should have saved the record and cleaned the form, it says the form is still dirty.
OK, you say, why do I care? Because the Form_BeforeUpdate event fires AGAIN when I try to navigate to a different record or when I try to close the form even if the navigate is the very next action after I click the COMMIT button. I have trap code in the BeforeUpdate event that is looking for a flag that says "OK to Update because the COMMIT button was used" But I have already updated the underlying and therefore reset the COMMIT-used flag by the time I try to select a new record or perform the close.
What this tells me is that a DoCmd to save a record doesn't reset the form's dirty flag. I didn't think that was possible.
I cannot post the DB because of DoD security issues. I'm just hoping that someone has seen a "persistent" form.Dirty flag before and remembers why it happens. I'm going totally nutso for this form. Has anyone seen this kind of behavior before? If so, what causes it?
Got a Form with a sub-form. Sub-form is locked because it is not updated from user action through that sub-form's controls - they are all locked. Some control buttons on the parent trigger a code sequence to do an .AddNew for the sub-form's recordset via VBA activities. The code does the .AddNew, fields get loaded in the record, .Update, .Close, and then I requery the sub-form.
The button that updates the sub-form saves the current record after it does some change auditing. I used the button wizard to build the skeleton and then edited the code to include the auditing. So I get to the point where I have done some VBA to update the sub-form and I requery the sub-form. The new record shows up fine.
Now I try to save the parent form with an updated status to match the last status code stored in the sub-form. (No, not storing a computed value... the sub-form new record holds the action status from the current status of the parent, not the other way around.) Once I requery the child record, essentially a detailed journal of action for the parent record, I want to also save anything updated on the parent. So I let the VBA code do what the button wizard created for saving records.
These two lines of code are driving me bonkers because they prove I don't understand the form Dirty flag. Before I enter this code, the form was dirty because I updated some data on the parent. SO I save it with...
Code:
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
bFrmSaysDirty = Me.Dirty
When I put a breakpoint on the second line of code, i.e. after a call that should have saved the record and cleaned the form, it says the form is still dirty.
OK, you say, why do I care? Because the Form_BeforeUpdate event fires AGAIN when I try to navigate to a different record or when I try to close the form even if the navigate is the very next action after I click the COMMIT button. I have trap code in the BeforeUpdate event that is looking for a flag that says "OK to Update because the COMMIT button was used" But I have already updated the underlying and therefore reset the COMMIT-used flag by the time I try to select a new record or perform the close.
What this tells me is that a DoCmd to save a record doesn't reset the form's dirty flag. I didn't think that was possible.
I cannot post the DB because of DoD security issues. I'm just hoping that someone has seen a "persistent" form.Dirty flag before and remembers why it happens. I'm going totally nutso for this form. Has anyone seen this kind of behavior before? If so, what causes it?