Me.Dirty reported False in OnCurrent but True in BeforeUpdate event when no data has been input

[VicM]

I admit I have posted this on Tek-tips a couple of days ago and have yet to receive any input.

Folks,
This by no means is a very critical problem. It's more annoying than anything else as it doesn't impact the user, just the developer (me!). LOL

Using Access 2010 on Win7 Pro box.

On my form I have a BeforeUpdate event:

Private Sub Form_BeforeUpdate(Cancel As Integer)
Debug.Print "From BeforeUpdate CurrentView = " & Forms("frmBooks Read").CurrentView
Debug.Print "From BeforeUpdate dirty = " & Me.Dirty
If Me.Unread = True And Me.Ebook = False And IsNull(Me.fraLocation) Then
    Beep
    MsgBox "Please enter a location for this book", vbOKOnly, "No Location Entered"
    Cancel = True
End If

End Sub

Whenever I try switching from the active form to design mode, the BeforeUpdate event is triggered and the message indicates that the "expression refers to an object that is closed or doesn't exist". The expression is testing if data was entered into some of the controls using the Me construct for the controls. If new data is being input, I want to ensure that certain fields are filled in as well.

If all I've done is open the form, change nothing and attempt to move to design mode, I get that error. So I've put some Debug.Print text in both the OnCurrent and BeforeUpdate events identifying the event and the status of the Dirty parameter.

If I move the record in the active form to the next record, I get the following info in the Immediate window:
From OnCurrent Dirty = False
From BeforeUpdate CurrentView = 1

From BeforeUpdate Dirty = True


From OnCurrent Dirty = False


If I don't move to another record after first opening the form and attempt to move to design mode, I get the following in the Immediate window:
From BeforeUpdate CurrentView = 1
From BeforeUpdate Dirty = True



Additionally, when this happens, the Debug.Print line is executed in the BeforeUpdate event (it's the first line of code in the event). The Debug.Print contains the Me.Dirty parameter. Yet the very next line of code which contains the Me.[control] If statement is where the cursor stops when I ask to Debug the error.

I'm confused as to why in the first circumstance the OnCurrent reports False for Dirty while the BeforeUpdate reports True.

Again, this only affects me when designing. It's not an issue for the user.

Any thoughts?
Thanks,
Vic

[ranman256]

i stopped using the Dirty. it was too much hastle.

[Micron]

just a guess but you have code in the close or unload event that is causing this, or a calculated field is putting the form in edit mode in some cases. Is the edit icon visible in the record selector (maybe show record selector temporarily if not currently shown). You may have to post a db copy for this to be solved as these can be hard to pin down.

Note: claiming that you cross posted is a good thing, but posting a link is very helpful. I for one don't want to search for your thread to see if I'm repeating an answer you got elsewhere between the time you posted and the time I answer.

[Micron]

i stopped using the Dirty. it was too much hastle.

I think that's just being employed in an attempt to figure out the problem?

[VicM]

Micron,
The only events on the form are the OnCurrent and BeforeUpdate. There are no calculated fields on the form.

A link to the Tek-Tips post is: tek-tips.com/viewthread.cfm?qid=1797114

There were no replies there as of this post.

Thanks,
Vic

[VicM]

Micron,

You got me to thinking. In the Current event I determine the status of an optionbox. Based on the option value I hide/disable one control and show/enable another. When I put the Debug.Print Me.Dirty in the Current event, I had it at the beginning of the code so it reported False. But when I added another Debug.Print line at the end of the Current event, it reported the Dirty parameter as True because of the machinations with the controls.

So if I change the Dirty parameter to False at the end of the Current event, the switch from Active form to Design view does not cause the error. However, I will have to ensure if any real data was input then the Dirty parameter is reset to True.

In any event (no pun intended) it explains why the Dirty parameter was set to True when tested in the BeforeUpdate event.

Thanks.

[Micron]

IF the option (or more correctly the frame) is bound then you certainly are editing a record via code. Since you know what causes it I'd suggest not manipulating .Dirty property as a solution for switching to design view. Users will never do that but your fix may cause user problems if you play around with that property.

[VicM]

Micron,
Thanks again for your words of wisdom. Will pursue other options.

Vic