BeforeUpdate causes MouseClick to not execute

[TheSmileyCoder]

Hi everyone, hope someone can help me.

Problem:
I have an event on a beforeUpdate of a textbox, which sets another hidden field on the same form. When my focus is in the textbox, and I click a command button, the beforeUpdate runs just fine, but it seems to 'Cancel' the click of the command button, so I have to press the command button once more.

The Textbox is a unbound field with the following code attached (Ignore any syntax errors, its typed from memory):

private sub tb_SetPassword_BeforeUpdate(Cancel)
  if nz(me.tb_SetPassword,'')='' then
    'Nothing
  else
    me.tb_Password=fstrEncrypt(me.tb_SetPassword)
  end if 
end sub

Purpose of the function is to take the typed password from the unbound field tb_SetPassword, encrypt it and store it in the bound (and hidden) field tb_Pasword, which will then be stored with the user record.

Other Details:
Using Access 2003.

How Can I make the clicked event fire as it should?

[missinglinq]

The Textbox is a unbound field with the following code attached (Ignore any syntax errors, its typed from memory):

I'm sorry, but this statement is simply inane. You expect us to troubleshoot your code, but you're only giving us the code as you remember it, not necessarily as it actually appears!

We also need to see the code attached to the command button, and possibly the code for the encryption function.

The one thing that stands out, in the code as you've posted it, is that

if nz(me.tb_SetPas sword,' ')=' ' then

is going to cause a syntax error to be thrown. The two pairs of single quotes need to be double quotes.

if nz(me.tb_SetPas sword,"")= "" then

I suppose that might be causing your problem, but as I said, we need to see the actual code for the items above in order to help you.

Welcome to Bytes!

Linq ;0)>

[TheSmileyCoder]

Thanks for your reply.

The code throws no syntax errors.(but yes it is a doublequote) Ive tried added a msgbox event to the command button, which does not fire the first time i click it (but the beforeUpdate event of the textbox runs). Second time I click it, the msgbox will appear (and there will be no beforeUpdate on the textbox) and no error msg. I therefore conclude it has no impact what the code of the command button is.

It seems access has more focus on the fact that im leaving the textbox (triggering the beforeUpdate) then what im leaving it for (the command button).

[missinglinq]

It does sound as if the BeforeUpdate event is grabbing control away from the command button and aborting its code. Does the button code fire on the first click if you don't enter anything into tb_SetPassword?

Linq ;0)>

[TheSmileyCoder]

Ok, tried changing code in the beforeUpdate of the textbox.

Private Sub tb_SetPassword_BeforeUpdate(Cancel As Integer)
    Debug.Print "beforeupdaterun"
end sub

The clicked command button would now fire correctly.

Changed it back to:

Private Sub tb_SetPassword_BeforeUpdate(Cancel As Integer)
    Debug.Print "beforeupdaterun"
    If Not Nz(Me.tb_SetPassword, "") = "" Then
        Me.tb_UserPassword = MD5Hash(Me.tb_SetPassword)
        Debug.Print "Setting Password"
    End If
End Sub

The Command button now requires too "clicks" before functioning. The odd thing is that my debug window actually shows the beforeupdaterun debug message, and the setting password twice, so it would seem the beforeupdate event runs each time.

I therefore tried to simply the issue, and take the MD5Hash out of the variables. Code now looks like this:

Private Sub tb_SetPassword_BeforeUpdate(Cancel As Integer)
    Debug.Print "beforeupdaterun"
    If Not Nz(Me.tb_SetPassword, "") = "" Then
        'Me.tb_UserPassword = MD5Hash(Me.tb_SetPassword)
        Me.tb_UserPassword = "Random String"
        Debug.Print "Setting Password"
    End If
End Sub

I still need to click twice to get the command button to work.

And in response to your questin missinglinq, if the textbox is not dirty, the beforeupdate event is not fired, and the command button works fine.

I made yet another test, in which i "dirtyed" another field in the form before trying to change the password. The beforeupdate and command button would now both fire correctly. So maybe its related to dirtying the form (I have no event tied to dirty form or to the forms beforeupdate).

So, hope that ^^ made sense, and that someone has a good suggestion! :) And thanks for the posts made allready.

[TheSmileyCoder]

In the end I solved this by adding a extra field to my table, one in which to write the password (in the form) but not store it.

The before update would then encode the password and store it in another field, after which it would wipe clean the field in which the user had actually written the password. This meant that the form would allready be dirty before the user clicked the save button. The mouseclick now executes as I want it too.

[NeoPa]

TheSmileyOne:
I therefore conclude it has no impact what the code of the command button is.

Talk about Blythe Spirit. The issue here is not about how it affects you or your code. The universe does not begin and end with your person.

Your hastily posted code has been viewed and considered by a number of volunteer experts who now, it seems, have been wasting their time, simply to save you the bother of expressing your problem clearly and accurately.

Let me copy in a post I've had to use before for those that needed telling :
When posting any code on here please :

1. Ensure you have Option Explicit set (See Require Variable Declaration).
2. Try to compile it. If it doesn't compile for any reason please explain that clearly - including the error message and which line of your code it appears on. Compilation is done from the Visual Basic Editor menu - Debug \ Compile Project (Where Project is the actual name of your project).
3. Copy your code (using the Clipboard - Cut / Copy / Paste) from your project directly into your post. Typing in code is not appreciated as it is likely to introduce typos which cause members to waste their time unnecessarily.
4. Ensure that the code in your post is enveloped within CODE tags. The hash (#) button in the posting page helps with this. Simply select your code and click on the hash button to have it enveloped automatically.

If all these points are covered then all members will be better able to understand, and therefore attempt to answer, your question.

Administrator.

[TheSmileyCoder]

The thread is about how when you run code that will dirty a form, it can cause the MouseClick event to not fire properly.

Yes, I will admit that I was wrong in posting code from memory instead of copy-pasting it, but missinglinq has allready bashed me for that once. You doing it again really serves no purpose besides boosting your ego and feeling superior.

Ive tried added a msgbox event to the command button, which does not fire the first time i click it (but the beforeUpdate event of the textbox runs). Second time I click it, the msgbox will appear (and there will be no beforeUpdate on the textbox) and no error msg. I therefore conclude it has no impact what the code of the command button is.

I do an analysis of when the code fires, and why it doesnt fire, and report my findings. I could have written anything in the code of the command button, which would not matter as it did not fire. In my oppinion it makes sense to report that since then I/we can focus our attention elsewhere.

While you are free to disagree I feel that I have done my best to express my problem as clearly and accurately as possible, and I have followed up on the issue with further analysis of my own, as well as posting when I found the underlying issue.

The BeforeUpdate of textbox tb_SetPassword (which is unbound and therefore does not give a dirty form when filled in) will update a bound field tb_UserPassword (and theryby dirtying the form). The dirtying of the form apparantly overrides/cancels the MouseClick operation. As written I eventually worked around it by making the tb_SetPassword into a bound field.

[TheSmileyCoder]

It does sound as if the BeforeUpdate event is grabbing control away from the command button and aborting its code. Does the button code fire on the first click if you don't enter anything into tb_SetPassword?

Linq ;0)>

You where somewhat on the right track, so I choose your answer as the best reply. The BeforeUpdate of the TextBox dirtys the form, and as far as I could tell its the forms OnDirty event (with no code attached) that cancels the MouseClick, since dirtying the form otherwise before running the BeforeUpdate on the textbox would make the MouseClick execute properly.

[NeoPa]

TheSmileyOne:
Yes, I will admit that I was wrong in posting code from memory instead of copy-pasting it, but missinglinq has allready bashed me for that once. You doing it again really serves no purpose besides boosting your ego and feeling superior.

Isn't it a shame that you didn't consider admitting that earlier, instead of arguing that it wasn't important anyway. That way I could happily have saved my effort. We quite like good manners here, and we try not to tolerate bad. You see that's bad for morale, as well as a bad example for any new posters reading through taking a note of the tone of our site. Hence we police this forum rigorously (to the best of our volunteer ability at least).

I wouldn't normally expect a relatively new member to understand that, but I would expect a little thought before jumping to wholly unwarranted conclusions.

TheSmileyOne:
I do an analysis of when the code fires, and why it doesnt fire, and report my findings. I could have written anything in the code of the command button, which would not matter as it did not fire. In my oppinion it makes sense to report that since then I/we can focus our attention elsewhere.

While you are free to disagree I feel that I have done my best to express my problem as clearly and accurately as possible, and I have followed up on the issue with further analysis of my own, as well as posting when I found the underlying issue.

I did notice that. I'm honestly impressed. That does put you a cut above the average poster and, were it not for the other comments, I would be keen to see more of you. As it is, I hope that your ego isn't too bruised and you do continue to post here, but know that we will continue to manage the site (and this forum particularly) rigorously. If you can live with that then Welcome to Bytes!