[AccessD] Allow edits = False is Allowing Edits!

Rocky Smolin rockysmolin at bchacc.com
Mon Nov 14 11:17:32 CST 2016


No automatic editing.

R


-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Heenan, Lambert
Sent: Monday, November 14, 2016 9:04 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Allow edits = False is Allowing Edits!

I seem to recall that if, when a form was opened, any change in code to any
bound data field would result in the AllowEdits property being ignored.  Is
there any automatic "editing" of new records going on? Adding a date edited
value or anything like that?


Lambert  

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Rocky Smolin
Sent: Monday, November 14, 2016 11:32 AM
To: 'Access Developers discussion and problem solving'; 'Off Topic'
Subject: [AccessD] Allow edits = False is Allowing Edits!

Dear Lists:

 

(Access 2010, Windows 10, all bound forms)

 

Client wants one user to not be able to add change delete any data except
for one field in one form.  No worries.  I already have hooks in for Access
level per user (read only, read/write, administrator). And there's not many
forms and only a few that have data entry/edit. So I made a new access level
- 2. (1 is read only, three is read/write). Since the client wasn't using
these controls that change was easy.

 

So in the dirty event of those forms I put:

 

Private Sub Form_Dirty(Cancel As Integer)

 

If gintAccessLevel < 3 Then

    MsgBox "Read Write Access Required", , vbExclamation

    Cancel = True

End If

 

End Sub

 

And that works perfectly for all of them.  Except for three. (Which are all
similar but attached to different table. )

 

So I cleverly modified the Dirty event of this form to read 

 

Private Sub Form_Dirty(Cancel As Integer)

    MsgBox "!"

If gintAccessLevel < 3 Then

    MsgBox "Read Write Access Required", , vbExclamation

    Cancel = True

End If

 

End Sub

 

And after entering a number and leaving that field.No ! appears.  A
breakpoint on the MsgBox statement confirms that the dirty event is not
triggering.

 

 

But there's more than one way to skin a cat. So in the open event of one of
those forms I put:

 

If gintAccessLevel < 3 Then

    Me.AllowAdditions = False

    Me.AllowEdits = False

    Me.AllowDeletions = False

Else

    Me.AllowAdditions = True

    Me.AllowEdits = True

    Me.AllowDeletions = True

End If

 

Poop!  Still allows editing.

 

Could the allow edits property be getting changed? So in the after update
event of one of the fields I put:

 

Private Sub fldSocietyCourseOfferingNumberOfParticipants_AfterUpdate()

    MsgBox Me.AllowEdits

End Sub

 

And when I put something into the
fldSocietyCourseOfferingNumberOfParticipants the message read False!

 

And yet, it will save that value.

 

So I changed the code in the after update event of
fldSocietyCourseOfferingNumberOfParticipants to read:

 

Private Sub fldSocietyCourseOfferingNumberOfParticipants_AfterUpdate()

    

    MsgBox "! " & gintAccessLevel

If gintAccessLevel < 3 Then

    MsgBox "Read Write Access Required", , vbExclamation

    Me.undo

End If

 

End Sub

 

And it obediently prints ! 2.  And that works - it undoes the change.  But I
would not like to have to put that code in the after update event of every
field on the three recalcitrant forms.

 

So now, of course, I'm looking for some either obvious or obscure reason why
these three forms are misbehaving.  Any suggestions welcome

 

MTIA

 

 

Rocky Smolin

Beach Access Software

760-683-5777

 <http://www.bchacc.com> www.bchacc.com

 <http://www.e-z-mrp.com> www.e-z-mrp.com

Skype: rocky.smolin

 

 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list