Setting AllowEdits in Code not reflected on Property sheet

  • Thread starter Thread starter Laurence Lombard
  • Start date Start date
L

Laurence Lombard

Why, if I run the CommandButton code

Sub CommandButton_click()
Me.AllowEdits = False
End Sub

is the change not reflected in the Form's Property Sheet. The effects also
seem to be different.

Thanks
Laurence
 
Changing the property in the Property Sheet while the form is in Design
view, effectively sets the default behavior for the form.

Changing the property while if form is running does not do that, but it does
affect how the form behaves for the rest of this session (i.e. while the
form is still open).

If the form is dirty, Microsoft (wisely) allows you to override the
AllowEdits and finish what you are doing. You may therefore want to code:
If Me.Dirty Then
Me.Dirty = False
End If
Me.AllowEdits = False
 
The code will not make a permanent change to your form's design - it's not
intended to. The modification to the property will be active for as long as
the form is open or until subsequent code changes it again.

In terms of the effects, can you provide more detail?
 
Thanks Allen & Cheryl for replying. I did not explain myself fully. I wanted
to see first if I would get a response as no-one responded to my posts at
microsoft.public.access!

By now I am also getting confused with all the permutations I have tried.

I have a form with subform (Invoices and Invoice details) and I want to
prevent changes to old invoices while allowing entry of new invoices.

If I change AllowEdits to No on the main form property sheet while keeping
it "yes" on the subform property sheet I can make additions to the main form
but not the subform (the new record indicator (*) for the subform is faded
out). This does not make sense. Can you explain.

I have resorted to the following code which looks quite cumbersome - is this
the best way to handle this?

Private Sub Form_Current()
If NewRecord = True then
With Me.Invoice_Details_Subform.Form
Me.AllowEdits = True
Me.AllowDeletions = True
Me.AllowAdditions = True
.AllowEdits = True
.AllowDeletions = True
.AllowAdditions = True

Else

Me.AllowEdits = False
Me.AllowDeletions = False
Me.AllowAdditions = False
.AllowEdits = False
.AllowDeletions = False
.AllowAdditions = False
End With

End If
End Sub

Allen made the following suggestion, but I don't quite follow in what
situation this would be applied. Please explain.
If the form is dirty, Microsoft (wisely) allows you to override the
AllowEdits and finish what you are doing. You may therefore want to code:
If Me.Dirty Then
Me.Dirty = False
End If
Me.AllowEdits = False
Click to expand...


Many Thanks
Laurence
 
Hi Laurence. Now I can see what you are talking about.
It does appear to be an inconsistency in Access.

If you set the form's AllowEdits property to No at design time, when you
open the form, Access applies the property to the subform control as well,
i.e. no changes or additions or deletions can be made in its subform.

However, if you set the form's AllowEdits to No after the form is open, you
can still edit, delete and append records in its subform. The behaviour is
inconsistent. I am seeing it both in Access 97 and 2003.

Your code in the main form's Current event looks like a satisfactory
workaround.

AllowEdits has another major limitiation also: it prevents users doing
anything with unbound controls as well! So if you have unbound controls on
the form for navigating or filtering or finding or ..., it turns out that
setting the form's AllowEdits is not very useful.

The previous point I was making was just that if you programmatically set
the form's AllowEdits to False while the form has unsaved edits, Microsoft
allows you to finish your edits and save the record before the new setting
(to disallow edits) cuts in. We often see people confused by this, e.g. if
they programmatically dirty the record and don't know it's dirty, they
complain that they can still edit after setting AllowEdits to No.
 
Another workaround: At design time, leave the form's AllowEdits as Yes.
Use Form_Load to programmatically set it to No whenever the form opens.
That should avoid the inconsistent behavior of the subform control.
 
Back
Top