AllowEdits - False not firing (1 Viewer)

[jpl458]

I have a form tham that is used to scroll through data, and occasionally edit some of that data. The form is initially set to AllowEdits = False, AllowAdditions = false. If the I want to edit data I must hit a button that unlocks editing. In the OnCLick event of that button I have the following code:

If Me.LockUnlockbtn.Caption = "Edit Locked" Then
    Me.AllowEdits = True
    Me.LockUnlockbtn.Caption = "Edit Unlocked"
    Me.LockUnlockbtn.BackColor = RGB(255, 0, 0)
    Else
    Forms!RoboMasterEntry.AllowEdits = False
    Me.LockUnlockbtn.Caption = "Edit Locked"
    Me.LockUnlockbtn.BackColor = RGB(238, 201, 0)
 End If

When the app open I can edit, but I have set the allowedits to fase in the on load event

and when I hit the button again, to lock the edits, I can still edit.

What part am I missing?
Blue in the face!
Thanks

 

[Josef P.]

Is "Me" and Forms!RoboMasterEntry the same form reference?

 

[jpl458]

Is "Me" and Forms!RoboMasterEntry the same form reference?

Yes. I should have taken the forms reference out before I posted. I just tried that to see if that would make it work. Here si the original code:

If Me.LockUnlockbtn.Caption = "Edit Locked" Then
    Me.AllowEdits = True
    Me.LockUnlockbtn.Caption = "Edit Unlocked"
    Me.LockUnlockbtn.BackColor = RGB(255, 0, 0)
    Else
    Forms!RoboMasterEntry.AllowEdits = False
    Me.LockUnlockbtn.Caption = "Edit Locked"
    Me.LockUnlockbtn.BackColor = RGB(238, 201, 0)
 End If

 

[bastanu]

From your scenario I think you are trying to edit a record then turn off the AllowEdits while the record is still dirty.

Try to add a Me.Dirty=False before your existing code and see what happens.

Cheers,

 

[jpl458]

From your scenario I think you are trying to edit a record then turn off the AllowEdits while the record is still dirty.

Try to add a Me.Dirty=False before your existing code and see what happens.

Cheers,

Actually, the problem is that I can't get the ALlowEdits = False to have any effect at all. When the form opens it is supposed to be locked, but I can edit to hearted content. AllowEdits = True never changes. Just put your suggestion at the top of the code, but nothing changed.

I just tried setting the AllowEdits = False in the OnCurrent event, and setting a button AllowEdit = True so editing can be done. But that didn't work either. I am suspecting that there is a setting elsewhere that is overriding everything, but I can't figure where it is.

 

[bastanu]

I think you're make it too complicated; open the form in design view and set the AllowEdits, AllowAdditions and AllowDeletes to No. Save the form.
Do not attempt to change it anywhere else but your button.
See this small sample. I have included another button that toggles the form RecordsetType property between 0 (dynaset) and 2 (snapshot) as it achieves a similar outcome with fewer lines of code.
Cheers,

 

[jpl458]

I think you're make it too complicated; open the form in design view and set the AllowEdits, AllowAdditions and AllowDeletes to No. Save the form.
Do not attempt to change it anywhere else but your button.
See this small sample. I have included another button that toggles the form RecordsetType property between 0 (dynaset) and 2 (snapshot) as it achieves a similar outcome with fewer lines of code.
Cheers,

Your code, worked, except for 1 part, when the form loads its unlocked. Tried putting AllowEdits = False in the onLoad event but that didn't work. The problem is getting the form to open locked. Now, once I run your code, and unlock and lock the form it works great after that. I've closed and opened the form and nothing changed.. I read something a about Mode setting on loading a form, but I think that has to do with DoCmd.

Thanks for the help

 

[bastanu]

To open the form locked switch to design view and go to form properties and set the three .Allow properties on the Data tab to No and save it. Remove any other code in the Load or Current events that are dealing with those properties.
Alternatively you can leave the 3 .Allow properties set to Yes but change the form's RecordsetType to snaphot as default (in design view) then use the code from my second button to toggle between dynaset and snapshot.

Cheers,

 

[jpl458]

To open the form locked switch to design view and go to form properties and set the three .Allow properties on the Data tab to No and save it. Remove any other code in the Load or Current events that are dealing with those properties.
Alternatively you can leave the 3 .Allow properties set to Yes but change the form's RecordsetType to snaphot as default (in design view) then use the code from my second button to toggle between dynaset and snapshot.

Cheers,

They have been set throughout the problem:

In addition I have cleaned out every spec of code from the events not involved. Saved the form, closed then reopened and the problem still exists.

 

[bastanu]

Puzzling.... Do you open the form from the Access built-in navigation pane? Could you add the form and its recordsource to an empty accdb and upload it here?

Cheers,

 

[jpl458]

When I open the app it goes to a menu screen. Then I open it there via na embedded maro that was created when I built the button choosing the open forms option. I move the form to a new accdb and see what happens.

Just loaded form, query that the record source for the form, and the Master table, and the results are the same. Starting to believe in Gremlins.

 

[bastanu]

Try to open the form directly from the navigation pane (open the app holding the Shift key to bypass the startup). According to this link having the Data Mode empty should open the form locked with your settings in place: https://support.microsoft.com/en-us/topic/8ece67cc-783c-4b2e-9f33-0e24e8436a05

Have you tried my other suggestion using the RecordsetType? Set those Allow properties back to Yes and set the form's recordsettype to snapshot and save it. Then use the code in my sample and see what happens.

Cheers,

 

[jpl458]

Try to open the form directly from the navigation pane (open the app holding the Shift key to bypass the startup). According to this link having the Data Mode empty should open the form locked with your settings in place: https://support.microsoft.com/en-us/topic/8ece67cc-783c-4b2e-9f33-0e24e8436a05

Have you tried my other suggestion using the RecordsetType? Set those Allow properties back to Yes and set the form's recordsettype to snapshot and save it. Then use the code in my sample and see what happens.

Cheers,

Haven't tried the snapshot trick yet but I will. Got to log off for a bit. Will try later.

 

[Pat Hartman]

When the app open I can edit, but I have set the allowedits to fase in the on load event

Property settings have to be toggled correctly and you can't leave it to the user. Yes, he can be trusted to unlock the form but he cannot be trusted to remember to lock it again and the form will always remember the most recent setting.

Rather than using the Load event which runs only ONCE when the form loads, you can use the form's Current event which runs each time you set focus to a different record.

Alternatively, you have to lock the form in the form's AfterUpdate event. So after the changed record is saved, you re-lock the form. Using the Current event is safer.

 

[jpl458]

I found the problem after a decent night's sleep. The form has a lot of text controls, some of which are invisible until something is entered in another control. Therefore I had a lot of cleanup to do when I went to a new record. I am doing this in the OnCurrent event when the next record has the focus. Part of the cleanup was changing the color of a button and setting AllowEdits and AllowAdditions to false. This AM I decided to put your code into my app and then I saw it. In the cleanup process just had to insert Me.dirty = False. Which you mentioned earlier, but I was looking in the wrong event.

And Voila'. My problem is I don't fully understand why it works. If Dirty = False then the current record must not have changed. Which means that the record is assumed to be Dirty on load, or something like that, and why?

Thanks so much for the help. And I learned something.

Property settings have to be toggled correctly and you can't leave it to the user. Yes, he can be trusted to unlock the form but he cannot be trusted to remember to lock it again and the form will always remember the most recent setting.

Rather than using the Load event which runs only ONCE when the form loads, you can use the form's Current event which runs each time you set focus to a different record.

Alternatively, you have to lock the form in the form's AfterUpdate event. So after the changed record is saved, you re-lock the form. Using the Current event is safer.

I followed your advice from a previous post and put all the action in the on current event. When the user goes to a new record I relock the data. But I can't get square in my head The Me.Dirty = False statement, (that made everything work as required). I believe it means that this record has not been changed. But if I open the app why does it assume the the first record it reads is dirty when I set the AllowEdits to False in the property sheet for the form?
I watched your video regarding the BeforeUpdate, but couldn't find the practice DB. Wanted to see how you loaded up the events list on the left side. Besides the great info in the video, displaying the events list was really cool. Seems to me, that would be helpful in developing complicated stuff.

The activity reaffirms what I've learned through the years and several languages, The only way to learn how to write code, is to write code.

Thanks again, Pat

 

[Pat Hartman]

In the cleanup process just had to insert Me.dirty = False.

BAD move. You absolutely do not want to force the record to save in the Current event. If your code is dirtying the record, then this will cause you to create bogus records. The user has done NO data entry at this point so the form should NEVER be dirty unless YOUR code is dirtying it. You need to find the code that is dirtying the form and remove it. Do you have validation code that prevents bad records from being saved?

Personally, I think you are probably making this harder than it needs to be. I've posted in numerous places that I rarely use AllowEdits = No to lock a form. If you know how to use the BeforeInsert, BeforeUpdate, and Dirty events, you don't ever have to lock the form at all. Setting AllowEdits to No breaks unbound controls that you use for searching which is the major reason.

I use the BeforeInsert event to keep the user from trying to add records in a subform before the parent record is created.
I use the Dirty event to trap the first keystroke and determine if ANY change should be allowed to the record. If no change can be allowed at this time, just use Me.Undo to back out the change. If you use a button to toggle the AllowEdits, set a variable that you test in the Dirty event. If the user didn't press the button to unlock the form, don't allow changes. If he did press the button, allow the edits to continue.

And the BeforeUpdate event is where you put your validation code (or call it from) in order to prevent bad data from being saved.

the sample database got uploaded toward the end of that thread with the video links.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[jpl458]

BAD move. You absolutely do not want to force the record to save in the Current event. If your code is dirtying the record, then this will cause you to create bogus records. The user has done NO data entry at this point so the form should NEVER be dirty unless YOUR code is dirtying it. You need to find the code that is dirtying the form and remove it. Do you have validation code that prevents bad records from being saved?

Personally, I think you are probably making this harder than it needs to be. I've posted in numerous places that I rarely use AllowEdits = No to lock a form. If you know how to use the BeforeInsert, BeforeUpdate, and Dirty events, you don't ever have to lock the form at all. Setting AllowEdits to No breaks unbound controls that you use for searching which is the major reason.

I use the BeforeInsert event to keep the user from trying to add records in a subform before the parent record is created.
I use the Dirty event to trap the first keystroke and determine if ANY change should be allowed to the record. If no change can be allowed at this time, just use Me.Undo to back out the change. If you use a button to toggle the AllowEdits, set a variable that you test in the Dirty event. If the user didn't press the button to unlock the form, don't allow changes. If he did press the button, allow the edits to continue.

And the BeforeUpdate event is where you put your validation code (or call it from) in order to prevent bad data from being saved.

the sample database got uploaded toward the end of that thread with the video links.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

Just when I thought I had it figured out....You pack so much into a small space.

Back to work, best practices.

Thanks, Pat

 

[jpl458]

Found the code that dirties the form. It's in the OnCurrent event. Form has a lot of popup text boxes that I clean out and make invisible when moving to another record. So it does it on the first record when the form is loaded, because it's OnCurrent. I cut all that code out and ran the form without the Me.Dirty and the locking worked fine. I already had the locking set up so when the user moves to another form the data is locked.

Looking for another apple

 

[Pat Hartman]

Life is so good when you understand form level events

 

[spaLOGICng]

I have a form tham that is used to scroll through data, and occasionally edit some of that data. The form is initially set to AllowEdits = False, AllowAdditions = false. If the I want to edit data I must hit a button that unlocks editing. In the OnCLick event of that button I have the following code:

If Me.LockUnlockbtn.Caption = "Edit Locked" Then
    Me.AllowEdits = True
    Me.LockUnlockbtn.Caption = "Edit Unlocked"
    Me.LockUnlockbtn.BackColor = RGB(255, 0, 0)
    Else
    Forms!RoboMasterEntry.AllowEdits = False
    Me.LockUnlockbtn.Caption = "Edit Locked"
    Me.LockUnlockbtn.BackColor = RGB(238, 201, 0)
End If

When the app open I can edit, but I have set the allowedits to fase in the on load event

and when I hit the button again, to lock the edits, I can still edit.

What part am I missing?
Blue in the face!
Thanks

If you have the Allow Edits set to False, Button Clicks will be ignored on that form.

The workaround that I have used is set the RecordsetType to Snapshot.

Form.RecordsetType property (Access) | Microsoft Learn