"On Dirty" Event not working right

A

Anthony

I have this bit of VB code on the "Click" event button that closes a form.

If Me.Dirty = True Then
If MsgBox("Do you wish to save changes?", vbYesNo, "Notice") = vbNo
Then
Me.Undo
DoCmd.Close acForm, "frm_Comments"
Else
DoCmd.Close acForm, "frm_Comments"
End If
Else
DoCmd.Close acForm, "frm_Comments"
End If

I thought I programmed this to ONLY pop up the message box if a change was
made on the form. However, the message box pops up regardless of whether I
made a change (Dirty) or not.
Here is some background on the form. This form with this Click event is a
pop up form from another form. This form has an "OnOpen" event that uses VB
to populate the form, so it is not populated from a query or table. I use a
Me.cbo_Issue04.RowSource = "SELECT " . . . code to populate the form upon
open.

Any help would be appreciated.
 
D

Dirk Goldgar

Anthony said:
I have this bit of VB code on the "Click" event button that closes a form.

If Me.Dirty = True Then
If MsgBox("Do you wish to save changes?", vbYesNo, "Notice") = vbNo
Then
Me.Undo
DoCmd.Close acForm, "frm_Comments"
Else
DoCmd.Close acForm, "frm_Comments"
End If
Else
DoCmd.Close acForm, "frm_Comments"
End If

I thought I programmed this to ONLY pop up the message box if a change was
made on the form. However, the message box pops up regardless of whether
I
made a change (Dirty) or not.
Here is some background on the form. This form with this Click event is a
pop up form from another form. This form has an "OnOpen" event that uses
VB
to populate the form, so it is not populated from a query or table. I
use a
Me.cbo_Issue04.RowSource = "SELECT " . . . code to populate the form upon
open.

Any help would be appreciated.


Either I'm not understanding your explanation, or it's incomplete. If the
form were actually unbound ("not populated from a query or table"), then a
reference to the Dirty property would raise an error. So I have to conclude
that the form actually is bound, and that you are dirtying it in code
somehow.

What is the RecordSource property of the form? If it's blank in design
view, are you setting it in the form's Open event? What is the full code
from the Open event? My guess is that there is code there that is assigning
values to one or more fields on the form, or in the form's recordsource.
 
A

Anthony

I never said the form was unbound. But, yes, as I said in my original
message, the Open event populates fields in the form. As soon as I sent
the original message, I realized this. I am "Dirty"ing the form
programmatically in the Open event. I put a "me.dirty = false" as the last
line in the Open Event Sub and NOW it works fine - the message box only pops
up when the user changes something on the form.
I am only a good enough VB programmer to get in trouble. Small, esoteric
details like this get me in trouble.
Thank You for answering my message so quickly. It is nice to know there are
REAL experts willing to help us.

BTW: When I was diagnosing the problem, I substituted the Me.Dirty with
Me.BeforeUpdate. I got the run-time error "Type Mismatch". What is the
difference between the two and when should one be used and not the other.
 
D

Dirk Goldgar

Anthony said:
I put a "me.dirty = false" as the last
line in the Open Event Sub and NOW it works fine

So you are always creating a record when the form opens, and the only
question will be whether the user wants to modify that record. Right?
Thank You for answering my message so quickly.

You're welcome. I'm glad to help.
BTW: When I was diagnosing the problem, I substituted the Me.Dirty with
Me.BeforeUpdate. I got the run-time error "Type Mismatch". What is the
difference between the two and when should one be used and not the other.

The form's BeforeUpdate property is a text property that determines whether
and how the form will react to the BeforeUpdate event. In Access 2003 and
before, if it's not blank it can have a value of "[Event Procedure]" or the
name of a macro. (In Access 2007, it can also contain an embedded macro,
but I'm not sure at the moment how that is represented.)

All those properties you see listed on the Event tab of the form's property
sheet are the "event" properties of the form, and they are very real
properties that tell the form how to behave. When you wrote:

If Me.BeforeUpdate = True Then

.... you forced a comparison between a string value (the value of the
BeforeUpdate property) and the boolean constant True. Since the string
value couldn't be converted to a boolean value for comparison, the Type
Mismatch error was raised.

Note that the form has two properties related to "dirtyness". The Dirty
property is a boolean property that returns the modified state of the form,
and can change that state if written to. The form also has an "OnDirty"
property, which is a text property that determines how the form will react
to the Dirty *event*; that is, to the event in which an unmodified record
on the form is modified.
 
A

Anthony

So you are always creating a record when the form opens, and the only
question will be whether the user wants to modify that record. Right?

well, I didn't' think I was always creating a record when the form is
opened, but maybe I am inadvertently creating one with the way I have
programmed the Open Event. The Open Event is for a pop-up form off another
form. When the form pops up, it is first blank. But after you fill it in
and close it, if you pop it up again, it will be filled in with what you
previously typed in.

Note that the form has two properties related to "dirtyness". The Dirty
property is a boolean property that returns the modified state of the form,
and can change that state if written to. The form also has an "OnDirty"
property, which is a text property that determines how the form will react
to the Dirty *event*; that is, to the event in which an unmodified record
on the form is modified.

AAAHH! I didn't realize I was using the boolean version of the Dirty
property when I set "Me.Dirty". All I knew is I wanted to program a way to
test if the form had been changed and if not, then close without asking to
save.

Dirk Goldgar said:
Anthony said:
I put a "me.dirty = false" as the last
line in the Open Event Sub and NOW it works fine

So you are always creating a record when the form opens, and the only
question will be whether the user wants to modify that record. Right?
Thank You for answering my message so quickly.

You're welcome. I'm glad to help.
BTW: When I was diagnosing the problem, I substituted the Me.Dirty with
Me.BeforeUpdate. I got the run-time error "Type Mismatch". What is the
difference between the two and when should one be used and not the other.

The form's BeforeUpdate property is a text property that determines whether
and how the form will react to the BeforeUpdate event. In Access 2003 and
before, if it's not blank it can have a value of "[Event Procedure]" or the
name of a macro. (In Access 2007, it can also contain an embedded macro,
but I'm not sure at the moment how that is represented.)

All those properties you see listed on the Event tab of the form's property
sheet are the "event" properties of the form, and they are very real
properties that tell the form how to behave. When you wrote:

If Me.BeforeUpdate = True Then

.... you forced a comparison between a string value (the value of the
BeforeUpdate property) and the boolean constant True. Since the string
value couldn't be converted to a boolean value for comparison, the Type
Mismatch error was raised.

Note that the form has two properties related to "dirtyness". The Dirty
property is a boolean property that returns the modified state of the form,
and can change that state if written to. The form also has an "OnDirty"
property, which is a text property that determines how the form will react
to the Dirty *event*; that is, to the event in which an unmodified record
on the form is modified.

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

(please reply to the newsgroup)
 
D

Dirk Goldgar

Anthony said:
I didn't' think I was always creating a record when the form is
opened, but maybe I am inadvertently creating one with the way I have
programmed the Open Event.

It sounds like it, from what you said about populating fields on the form in
its Open event. If the form is displaying an existing record, that would
presumably change the fields in the record unless you have code to prevent
that, and if the form is displaying a new blank record, that would create a
new record that would be saved when you close the form -- unless, of course,
you undo the changes.
 
L

Larry Linson

Anthony said:
I never said the form was unbound. But, yes, as I
said in my original message, the Open event populates
fields in the form. As soon as I sent the original message,
I realized this. I am "Dirty"ing the form programmatically
in the Open event. I put a "me.dirty = false" as the last
line in the Open Event Sub and NOW it works fine -

Perhaps, only perhaps... are you aware that the Me.Dirty = False statement
causes the Record to be immediately saved? I didn't get the impression
that's what you wanted to do, but wanted to wait until the user had entered
data.
the message box only pops up when the user changes
something on the form. I am only a good enough VB
programmer to get in trouble.

If you only wanted the record saved when the user makes a change, as I
thought you wanted, then you did "get yourself in trouble".

But, if we understood what you have, what you want to accomplish, and the
_details_ of what you are doing, then we would be in a better position to
help. There are multiple ways to open a form... data entry being for
creating a new record, edit being for modifying an existing record OR
allowing creation of a new record... we can assume you are opening in data
entry mode if you are partially populating the record in the Open event, but
that will not necessarily be a correct assumption. It is difficult, at best,
to debug remotely; without all the details, it can be impossible.
Small, esoteric details like this get me in trouble.

I'm not certain which detail(s) you mean, but I am also not certain I'd
agree that the details that caused you trouble in this situation are either
small or esoteric. They are just, I'd say, the way Access is designed (and
documented) to work. It did not help, of course, that somewhere along the
versions, Microsoft stopped including a good set of printed manuals with the
product, and that they have had a struggle to create a good help system
since Access 97 (some would contend "since Access 2.0").

Larry Linson
Microsoft Office Access MVP
 
A

Anthony

Perhaps, only perhaps... are you aware that the Me.Dirty = False statement
causes the Record to be immediately saved? I didn't get the impression
that's what you wanted to do, but wanted to wait until the user had entered
data.

Yes, I do want to wait until the user had entered data, but since the save
(Me.Dirty = FALSE) is before the user has done anything (it happens right
when the form is opened), it becomes a moot point.
I'm not certain which detail(s) you mean, but I am also not certain I'd
agree that the details that caused you trouble in this situation are either
small or esoteric. They are just, I'd say, the way Access is designed (and
documented) to work. It did not help, of course, that somewhere along the
versions, Microsoft stopped including a good set of printed manuals with the
product, and that they have had a struggle to create a good help system
since Access 97 (some would contend "since Access 2.0").

If all someone needed to do was read a book on Access and they were experts,
I guess this message board would be blank. When I say, "small, esoteric
details" I mean those things that you only understand and gain experience by
DOING. There are subtleties (small, esoteric details) in all programming
that you just can't get from reading a book, it may takes years to fully
understand them. It wouldn't matter if MS writes a manual on Access that
wins a Nobel in Literature and is on the same high school reading list as
Hemingway, Chekhov and Jane Austen, there are going to be small, esoteric
details of the VB language that you are just not going to get without
experience - in some cases, years of experience.
 
L

Larry Linson

Anthony said:
Yes, I do want to wait until the user had entered data, but since the save
(Me.Dirty = FALSE) is before the user has done anything (it happens right
when the form is opened), it becomes a moot point.

Perhaps, perhaps not. If the user quits without entering anything, you will
have a probably-useless record saved in your database containing only the
"autofilled" fields. If you can handle these fields with a Default Value, I
believe that will give you what you want because the default value will not
cause the record to be saved, and you won't have to use Me.Dirty = False.

Larry Linson
Microsoft Office Access MVP
 
C

Clif McIrvin

(comment at end)

Larry Linson said:
Perhaps, perhaps not. If the user quits without entering anything,
you will have a probably-useless record saved in your database
containing only the "autofilled" fields. If you can handle these
fields with a Default Value, I believe that will give you what you
want because the default value will not cause the record to be saved,
and you won't have to use Me.Dirty = False.

Larry Linson
Microsoft Office Access MVP


I have been learning about changing the default value "on the fly" ---
you are not limited to whatever default value (if any) was set at design
time.

An easy test to see if this will work for you would involve a simple
change to the code you have now to set the .DefaultValue property of the
control instead of the .Value property. I confess that I have not
discovered why sometimes I need to wrap the value in "double quotes" and
sometimes I don't ... perhaps it's a difference between a text box
control and a combo box control; and I think dates need to be wrapped in
#date literal# characters.
 
G

gaetano

Anthony said:
I have this bit of VB code on the "Click" event button that closes a form.

If Me.Dirty = True Then
If MsgBox("Do you wish to save changes?", vbYesNo, "Notice") = vbNo
Then
Me.Undo
DoCmd.Close acForm, "frm_Comments"
Else
DoCmd.Close acForm, "frm_Comments"
End If
Else
DoCmd.Close acForm, "frm_Comments"
End If

I thought I programmed this to ONLY pop up the message box if a change was
made on the form. However, the message box pops up regardless of whether
I
made a change (Dirty) or not.
Here is some background on the form. This form with this Click event is a
pop up form from another form. This form has an "OnOpen" event that uses
VB
to populate the form, so it is not populated from a query or table. I
use a
Me.cbo_Issue04.RowSource = "SELECT " . . . code to populate the form upon
open.

Any help would be appreciated.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top