AllowEdits Bug? (2 Viewers)

[xPaul]

Hi all,

I was wondering if someone could confirm/deny and inform me of any workaround for what I feel is a bug within Microsoft Access VBA?

Steps to reproduce:

• Create a form with a text box that is bound to a table, and ensure that text box is bound to a column.
• Set the form's AllowEdits property to false
• Change to form view
• Ensure that you cannot type a value into the textbox
• Run in the immediate window - forms!<your form name>.<your text box name>.value = "<a value of your choosing>"
• Your "<a value of your choosing>" should now be present in the text box
• Click into the text box and type, your typing should appear in the textbox

In response to this I have the following questions:

1. Can anyone explain why this happens?
2. Is there an acceptable workaround for this?

Cheers!

 

[Ranman256]

Because you went OUTSIDE the form , behind the scenes to do this.

Most users cannot do this and dont know how. They just enter values into the form.
ANYTHING can be done in the background with tables and code.
To prevent, users would have to NOT have Ms Access, but runtime instead.
The runtime will not allow editing behind the scenes.
(but really, what user is gonna spend time digging thru code and forms to hack the data? )

 

[xPaul]

Because you went OUTSIDE the form , behind the scenes to do this.

Most users cannot do this and dont know how. They just enter values into the form.
ANYTHING can be done in the background with tables and code.
To prevent, users would have to NOT have Ms Access, but runtime instead.
The runtime will not allow editing behind the scenes.

Yes, you are absolutely right, hence the reason for this post. My code is causing this issue to happen which I do not want. I am currently completing this within a test environment to test my code, of course my end users will not be able to do this, I have simply outlined the steps to reproduce this to confirm/see what other alternatives are available . . .

 

[Ranman256]

runtime is your best prevention.

 

[xPaul]

runtime is your best prevention.

I don't think you quite understand.

Regardless of whether or not I use runtime, the same issue will ensue because the process that I am running is similar to the one outlined in my first post - I am using code to modify a text box value which then somehow allows the control to be edited whilst AllowEdits is still false.

 

[Galaxiom]

I have simply outlined the steps to reproduce this to confirm/see what other alternatives are available . . .

The alternative is to use intelligent code.

AllowEdits is about the user interface. The code is outside that interface. Not a bug but your misunderstanding.

It is like asking why a car doesn't stop at a red light when the driver decides to ignore it.

Anticipating your next question here. The code won't trigger the OnChange event of the textbox either. Not a bug either.

 

[xPaul]

The alternative is to use intelligent code.

AllowEdits is about the user interface. The code is outside that interface. Not a bug but your misunderstanding.

It is like asking why a car doesn't stop at a red light when the driver decides to ignore it.

Anticipating your next question here. The code won't trigger the OnChange event of the textbox either. Not a bug either.

Thanks for your input Galaxiom!

Basically what I am trying to achieve is to change a textbox value on the form whilst allowedits is false, but once the textbox is changed programmatically the control will still remain uneditable to the end user.

Do you have any examples, or point me in the right direction?

Thanks in advance.

 

[Ranman256]

you are confused.
a user CANNOT change the mode from the form to grid to alter data.
allowedits = false, a user will not be allowed to edit, nor defeat the setting by going behind the scenes in runtime.

 

[xPaul]

you are confused.
a user CANNOT change the mode from the form to grid to alter data.
allowedits = false, a user will not be allowed to edit, nor defeat the setting by going behind the scenes in runtime.

I am far from confused. I fully understand that my end users cannot and they do not have access to the VBA Editor nor Design View of any form.

I have developed a procedure which changes a text box value whilst the form is in AllowEdits = False. Once my procedure is ran, the text box is then fully editable by the end user on the form (as if AllowEdits = True). I would like the control to stay as it was prior to running my procedure, i.e. not editable.

 

[Minty]

XPaul Is correct - if you lock a whole form for edits then modify one of the controls contents in code it saves the changes!

News to me

To be honest I always lock the individual controls ,you can then change the contents without this behaviour happening.

 

[spikepl]

Once my procedure is ran, the text box is then fully editable by the end user on the form

Huh? That does not happen by itself. So you must have code that makes this change.

I would like the control to stay as it was prior to running my procedure, i.e. not editable.

Then do not do the change in the AllowEdits.

As Galaxiom said: all these settings determine what is allowed in the user interface. In code you can still do whatever you like.

 

[Minty]

Huh? That does not happen by itself. So you must have code that makes this change..

Spike - try it for yourself - it does.
Set a form to not allow edits.
Test that you can't edit the contents.
Put a command button on it that in code alters the value of one of the controls.
After pressing the cmd button Go to the control and miraculously you can now edit the contents.

 

[spikepl]

Just tried. Unable to reproduce this behaviour. Can you attach your test db? And with instructions so we look at exactly the same thing.

 

[Minty]

Here goes - watch out for the mega long code snippets

 

[spikepl]

Interesting (Read: I've no effing idea)

This is not supposed to happen. I'nm running A2010 on W7 and it is happening!

 

[Minty]

It's very interesting !!

I personally don't remember using don't allow edits in conjunction with code driven altering of data, generally if the form is read only I don't alter anything on it, but it is a massive gotcha! if you didn't realise it would do this...

Anyone else care to put their 2 cents worth in?

 

[spikepl]

Anybody contributing here please state which access and which windows

 

[spikepl]

I even tried to set AllowEdits=False in the code just after your assignment line, but it still allows manual edits!

 

[Minty]

This happens in Windows 8.1 - Access 2010

I can also confirm that it DOESN'T appear to happen on Access 2003 running on XP
(An old dev machine I have still running!)

 

[spikepl]

Would be interesting to see if A2013 also does it.