DoMenu Action Canceled

  • Thread starter Thread starter Robert T
  • Start date Start date
R

Robert T

I have a simple little Time & Attendance database which tracks my time and
attendance at work. That seems pretty logical, doesn't it?

1. All of the fields are default values that kick in when I click on the New
Rec button.
2. If there are no changes to the default values, I click on the Save Record
button.

Everything works well, however, I had to make a recent code change to ensure
the calculated week number field [in the table itself] was accurately
recorded. That in turn created a bizarre little problem. When I click on the
Save Record button, a dialog box pops up advising the DoMenu Action was
canceled. Despite that message, I click on the OK button and the record is
saved. Here's the code behind the Save Record button.

DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

Any suggestions?

Robert
 
Robert,

You need to move away from the DoMenuItem syntax to something that is a
little more reliable, and a little more readable.

In this case, you should be able to replace this line with:

me.dirty = False

Whenever a record is dirty (has changed from its original state), the forms
Dirty property is set to true. By setting it to false, you force Access to
save the current record.

HTH
Dale
 
First of all, I would not use the DoMenuItem syntax as that is not the most
current code. If you are using Access 97, then yes you will have to use
that, but if you are using Access 2000 or above you should be using the
RunCommand syntax:

DoCmd.RunCommand acCmdSaveRecord will do

or you can use

If Me.Dirty Then Me.Dirty = False

to save it.
--
Bob Larson
Access World Forums Super Moderator
Utter Access VIP
Tutorials at http://www.btabdevelopment.com
__________________________________
If my post was helpful to you, please rate the post.
 
Dale and Bob:

Thanks guys for the prompt, informative replies.

For your information, I didn't write that code, I used the Command Button
Wizard to create a Save Record button in Access 2003. If that code is no
longer viable, why is the Command Button wizard still using it?

Robert
 
Bob:

I inserted your code and now a dialog box is popping up advising the Run
Command was canceled. Do you think it's because of the Me.Dirty = True Line
in the code below?

Private Sub btnSaveRec_Click()
On Error GoTo Err_btnSaveRec_Click
Me!Week.SetFocus
Me.Dirty = True

DoCmd.RunCommand acCmdSaveRecord
Exit_btnSaveRec_Click:
Exit Sub

Err_btnSaveRec_Click:
MsgBox Err.Description
Resume Exit_btnSaveRec_Click

End Sub
 
Robert,

Bob said to use one or the other. delete the runcommand line from your code
and it should work fine.

Dale
 
Dale:

Thanks, I didn't catch that reference to one or the other. I need the
Me.Dirty = True command, otherwise the cursor won't go to the week field.

Therefore, I removed the Run Command, and you were right, it worked perfectly.

Thanks for your help,
Robert
 
Robert T said:
Bob:

I inserted your code and now a dialog box is popping up advising the Run
Command was canceled. Do you think it's because of the Me.Dirty = True
Line
in the code below?

Private Sub btnSaveRec_Click()
On Error GoTo Err_btnSaveRec_Click
Me!Week.SetFocus
Me.Dirty = True

DoCmd.RunCommand acCmdSaveRecord
Exit_btnSaveRec_Click:
Exit Sub

Err_btnSaveRec_Click:
MsgBox Err.Description
Resume Exit_btnSaveRec_Click

End Sub
Click to expand...


If I understand you correctly, you're setting Me.Dirty = True to force the
record to be dirty, because you aren't changing any of the default values.
Is that right?

Then you're setting the focus to Me!Week because there's some code that has
to run in that control's GotFocus or Enter event. Is that right, too?

My guess is that whatever is happening in that event is preventing the
record from being saved. Maybe it's just that the event has to finish
running first -- this could be a synchronization problem. Try adding the
line

DoEvents

after Me!Week.SetFocus, and see if that does the trick.

Or better, just call that event procedure directly, rather than setting the
focus to the control:

Call Week_GotFocus
Me.Dirty = True
Me.Dirty = False ' or RunCommand acCmdSaveRecord

Does that work?
 
Hello Dirk:

With one exception, everything you said was true. The first field [Primary
Key] is ID_No, the 2nd field is Date_Worked [Today's Date], and the third
field is the Week field.

Up until last week, the default for the Week field didn't work properly when
the date of the record was in a previous week. Therefore, I put the focus on
the Week field because that was the one field that was giving me problems, so
I thought it would be nice to start there and manually correct the problem.
However, there is no code being run from that field and another code change
fixed the problem I had with the accuracy of the Week Field Number.

The recommendations of Dale and Bob solved my problem. Apparently the
Me.Dirty and RunCommand were both trying to save the record as I didn't
realize the Me.Dirty line was also saving the record. When I deleted the
RunCommand line, that fixed the problem.

Nonetheless, I like your nifty suggestion and will keep it in mind for other
scenarios.

Robert
 
Dirk:

I tried all of your suggestions and none of them worked. Could the following
code be the culprit?


Private Sub Form_AfterUpdate()
Me.Week = Format(Me.Date_Work, "ww")

'After a user edits a record, this code will prevent accidental edits
'The user will have to click on the Allow Edits button again
Me.AllowEdits = False
End Sub

Private Sub Form_Load()
'Ensure that only new records are allowed
'Allow Edits to old records by clicking an Allow Edits button
Me.AllowEdits = False
End Sub

Robert
-------------------------------------------------------------------
 
Robert T said:
The recommendations of Dale and Bob solved my problem. Apparently the
Me.Dirty and RunCommand were both trying to save the record as I didn't
realize the Me.Dirty line was also saving the record. When I deleted the
RunCommand line, that fixed the problem.
Click to expand...


Setting Me.Dirty = True doesn't save the record; however, it *does* mark
the record as dirty so that it will be saved in the normal course of things,
when you close the form or move to a new record. So you get the effect you
want, with no need for the extra line to force the save immediately.
 
Robert T said:
Dirk:

I tried all of your suggestions and none of them worked. Could the
following
code be the culprit?


Private Sub Form_AfterUpdate()
Me.Week = Format(Me.Date_Work, "ww")

'After a user edits a record, this code will prevent accidental edits
'The user will have to click on the Allow Edits button again
Me.AllowEdits = False
End Sub

Private Sub Form_Load()
'Ensure that only new records are allowed
'Allow Edits to old records by clicking an Allow Edits button
Me.AllowEdits = False
End Sub
Click to expand...


If Week is a bound control, changing it in the form's AfterUpdate event will
dirty the form again, forcing another save. Maybe that's the source of your
problem. Use the BeforeUpdate event instead.
 
Good catch, Dirk.

I was so wrapped up in the the original two replies to Roberts post that I
didn't catch that he had changed

me.Dirty = False
to
me.Dirty = True

Dale
--
Don''t forget to rate the post if it was helpful!

email address is invalid
Please reply to newsgroup only.
 
Hello Dirk:

I don't have time to check it this afternoon, but will look at that
tomorrow. However, I wanted to take a quick moment to advise that Week is a
bound control. Why? Because the value will never change.

Robert

:
If Week is a bound control, changing it in the form's AfterUpdate event will
dirty the form again, forcing another save. Maybe that's the source of your
problem. Use the BeforeUpdate event instead.
 
Hey Guys:

In the end, I commented out everything except for this line:

DoCmd.RunCommand acCmdSaveRecord

So far, that seems to be working well.

I want to thank everyone for their comments. If nothing else, this was an
interesting and educational thread.

Robert
 
Back
Top