Dirty property not changing?

  • Thread starter Thread starter Rob Rutherford
  • Start date Start date
R

Rob Rutherford

Win XP Home, Access 2002.

I edit a record in a form so that the pencil symbol is showing in the record selector. If I then close the form, Me.Dirty is False
in the form's Unload event. I don't understand this and would be grateful for advice.
 
Rob Rutherford said:
Win XP Home, Access 2002.

I edit a record in a form so that the pencil symbol is showing in the
Click to expand...
record selector. If I then close the form, Me.Dirty is False
in the form's Unload event. I don't understand this and would be grateful
Click to expand...
for advice.

The record has already been saved by the time the Unload event occurs. If
you are trying to trap a condition before the Dirty condition becomes false,
use the Form's BeforeUpdate event.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access
 
That is the normal result since the edited Record has been saved by the time
the Form_Unload Event occurs.

In the Form_BeforeUpdate, the Dirty will be True if the Record has been
dirtied and after saving, the Form_AfterUpdate Event will show Dirty =
False. Bothe of these Events happen well before the Form_Unload Event.

--
HTH
Van T. Dinh
MVP (Access)




Rob Rutherford said:
Win XP Home, Access 2002.

I edit a record in a form so that the pencil symbol is showing in the
Click to expand...
record selector. If I then close the form, Me.Dirty is False
 
Hey - while on the subject, what makes the dirty condition kick? Is it
only when data has been modified? I've had calculated fields which have
changed because of changes to their components, but this doesn't seem to
kick the Dirty event.
 
grep, that is true. a calculated control is not bound to the record so
therefore changing its value does not put the record in a dirty state of
mind;-). If however, changes to bound controls of the record are what is
changing your calculated controls value, then this will place the record in
the dirty state. Moving focus to a control outside of the current record,
like a button in your header, or to a different record, will cause access to
save the record automatically. Hope this helps!
 
Reggie said:
grep, that is true. a calculated control is not bound to the record so
therefore changing its value does not put the record in a dirty state of
mind;-). If however, changes to bound controls of the record are what is
changing your calculated controls value, then this will place the record in
the dirty state. Moving focus to a control outside of the current record,
like a button in your header, or to a different record, will cause access to
save the record automatically. Hope this helps!
Click to expand...
Reggie,

Thanks for the explanation. I want to make sure I understand something
though. So the "being dirty" is a record-thing, not a field-thing? I
guess I'm not clear on why individual fields can have a dirty event if
the event isn't really applicable to them directly.

Practically, I want to have, the calculate field be updated as the user
looks at the form. The fact that it will be updated when the record is
saved is nice, but it's not going to forestall user confusion when they
don't see the math done right.

Thanks again.

grep
 
grep, Actually if you open the form and view the properties for a
field/unbound control, you wont see a Dirty property at that level. Dirty
is at the record level. However, if you have a calculated control on your
form, and you set the control source to something like below, the value will
change when you change the values in the fields
=(Nz([MyField1],0))+(Nz([MyField2],0))
Hope this helps
 
Reggie said:
grep, Actually if you open the form and view the properties for a
field/unbound control, you wont see a Dirty property at that level.
Dirty is at the record level. However, if you have a calculated
control on your form, and you set the control source to something
like below, the value will change when you change the values in the
fields =(Nz([MyField1],0))+(Nz([MyField2],0))
Hope this helps
Click to expand...

Although I agree with you in principle, Reggie, you may not be aware
that in Access 2002, at least, data controls do have a Dirty event.
 
Reggie said:
grep, Actually if you open the form and view the properties for a
field/unbound control, you wont see a Dirty property at that level. Dirty
is at the record level. However, if you have a calculated control on your
form, and you set the control source to something like below, the value will
change when you change the values in the fields
=(Nz([MyField1],0))+(Nz([MyField2],0))
Hope this helps
Click to expand...

I'll thank Dirk for the sanity check - thought I was going nuts for a
sec there. :)

I see what you're saying, Reggie. It makes sense. I think now that the
reason I was seeing the problem is because one of the source fields is
in a subform, and I couldn't figure out how to reference it besides
dlookup or dsum. That works, but it means that I have to requery.

So Dirk, in that case, what DOES the Dirty event do, as pertains to a
control - not a record?

grep
 
Ooops. Haven't made it that far yet. Sooorry!

--
Reggie

----------
Dirk Goldgar said:
Reggie said:
grep, Actually if you open the form and view the properties for a
field/unbound control, you wont see a Dirty property at that level.
Dirty is at the record level. However, if you have a calculated
control on your form, and you set the control source to something
like below, the value will change when you change the values in the
fields =(Nz([MyField1],0))+(Nz([MyField2],0))
Hope this helps
Click to expand...

Although I agree with you in principle, Reggie, you may not be aware
that in Access 2002, at least, data controls do have a Dirty event.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...
 
grep said:
So Dirk, in that case, what DOES the Dirty event do, as pertains to a
control - not a record?
Click to expand...

As nearly as I can make out, the Dirty event occurs for forms, text
boxes and combo boxes. For the controls, it fires when the text
displayed is first changed by user action. For the form, it fires when
the data in the current record is first modified in any way. Unlike the
Change event, the Dirty event doesn't fire when an already "dirty"
control is further modified.
 
grep, If you want to see it on your main form you can reference the controls
on your subform instead of using dlookup. If you already have a control on
your subform that does the calculation then just reference that control by
setting the control source of an unbound control on you main form to:
=Nz([MySubform]![MyControlOnSubform],0)
 
Reggie,

Yeah, I guess I can if I'm just trying to read that field. Problem was I
was trying to do nz(sum([MySubform]![MyControlOnSubform]),0). That
doesn't work. I either have to use dsum, or I have to create a control
on the subform to sum(), and then reference it on the main form.

Thanks for helping me clear that all up, though.

grep
 
Back
Top