how to prevent running OnExit procedure, if pressing Cancel Command?

[Sándor Demeter]

a textbox has an OnExit procedure that I don't want to run, if I pressed "Cancel command" button (a command button that I want to dedicate to this role).

before Cancel command button takes the focus, anyway the procedure linked to the OnExit event of the text box RUNS!

Is there a way to intercept the command button pressed, before OnExit runs?
KeyDown traps only the keys, not the command buttons. Am I wrong? Though should be something similar...
MouseDown runs only after the textbox's Exit proc
help needed

[NeoPa]

You've lost me. You use the word Cancel in so many different ways in the same sentence, to mean different things. As you never make it clear what each is supposed to mean it's very hard to understand what you're asking. From your name I guess English isn't your first language, but if you could try to ask the question again, and make it clearer what you're referring to, I expect we could help.

Most event procedures (you don't mention them by name anywhere, but I suspect you're dealing with one anyway somewhere in all this) have a parameter called Cancel if they can be interrupted. If one doesn't exist then the event itself cannot be skipped. That doesn't necessarily mean you can't have what you want, but we would need to understand what that is if we're to help.

[Oralloy]

What is stopping you from intercepting the OnExit and examining the event?

[Sándor Demeter]

First of all, thank you for the reply an sorry for not being clear enough.

Let's put it this way:
Access 2003, VBA
Form: unbounded
tb_One: text box one
has a procedure linked to the OnExit event that makes some control on the value entered on tb_One

tb_Two: the next text box on the form

cb_Cmd_button: a command button
if pressed, I want to cancel tb_One's edit and don't want to validate it's content

Let's suppose I'm editing tb_One and I want to get out from editing it. I don't care about the value already entered, so I don't want any validation for it.
How can I do it?

If I trap the key pressed while on tb_One (procedure linked on KeyDown event of tb_One), it works (see below)

Dim bl_Esc As Boolean
 
Private Sub tb_One_KeyDown(KeyCode As Integer, Shift As Integer)
    bl_Esc = False
    If (KeyCode = vbKeyEscape) Then
        bl_Esc = True
    End If
End Sub
 
Private Sub tb_One_Exit(Cancel As Integer)
On Error GoTo Err_Handler
    If bl_Esc Then
        GoTo endit
    End If
 
    '================
    'SOME VALIDATION PROCEDURE    I want to skip, if cb_Cmd_button is pressed
    '================
 
endit:
Exit Sub
 
Err_Handler:
    MsgBox "..."
    Resume endit
End Sub

But I want the same result obtained pressing cb_Cmd_button.
How can I realize at the begining of tb_One_Exit that cb_Cmd_button has been pressed?

Thank you again for your patience
Sándor

[Sándor Demeter]

perfect idea... how should I do it?
for a key pressed I use KeyDown event on the textbox...
but I don't know how to trap MouseDown before the OnExit event fires on the textbox I want to leave

[Oralloy]

First off, I'm using VBA embedded in Excel 2007. Your mileage may differ....

Ok, I just tried to prototype this, and got egg all over my face. I am at a bit of a loss.

Perhaps you need to have a global validator method, which is called by the Enter() methods; Exit() methods which record the last control exited. The validator would validate based on context and control values, and set the focus to the failing control, when appropriate?

I'm sorry that I'm not more help.

[Sándor Demeter]

Hi Oralloy,
I wouldn't like to let the user go until the end and then tell him he made a mistake...
on the other hand...
there is a sequence of text boxes / combo boxes / option groups... each one depends on the previous ones... so... I just can't wait to validate on the end :-(

Thank you for the answer :-)

[Oralloy]

I'm not saying that you should let go until the very end.

What I'm suggesting is that you can re-structure how you do your validation.

Essentially, move the validation to a global method.
In each Exit method, record the control that's exiting.
In each Enter method, validate, and if invalid, return to the exited control.

It's a lot of code to accomplish what you want, but I don't see anything easier.

[Sándor Demeter]

so you suggest me to run the validation not on the exit event but on next control's enter... not always acceptable... sometimes, depending on the value entered, the next control is a pop-up form... well ... I could put the validation on the OnOpen / OnLoad event... if I don't find a better solution... it might work...
anyway... isn't it strange, that I can't trap a command button (on MouseDown) while inside editing a textbox?

[Oralloy]

I am a little surprised that the MouseDown event fires after the Exit event. I'm sure there is a windoze logic to it, but I can't, for the life of me, figure out that it is right now.

Since I don't know the complexity of the form you're building, I really can't offer any other suggestions. If it's a small number of controls, it shouldn't be bad; on the other hand, if there are a large number of controls, it might be quite obnoxous.

And, while I'm thinking out loud, I'll suggest that you prototype the behaviour on a small test form, just to make sure you can tune it the way you want to. Nothing worse than doing a major refactor to expose some functionality, only to find out that it won't work anyway.

Luck!

[Sándor Demeter]

ok... thanks... working on it (test form)...
surprisingly even for me, MouseDown is felt only AFTER exiting the control edited

[NeoPa]

There's some quite clever thinking going on in here, but I have to say that expecting the Mouse-Down event to fire before the Exit event of the control that currently has focus seems very strange to me. Can you imagine how things would work if they designed it that way. I can, but I see nothing good.

Oralloy's suggestion, which was clarified in post #8, seems a clever solution though. I would recommend progressing with it.

[Sándor Demeter]

it seems that:

"if a control has the focus and you click another control to move the focus to this second control, the following sequence of events occur:
First control:Exit > LostFocus
Second Control:Enter > GotFocus > MouseDown > MouseUp > Click"

unlike:

"if a keystroke causes the focus to move from one control to another control, the KeyDown event occurs for the first control
First control: KeyDown > BeforeUpdate > AfterUpdate > Exit > LostFocus
Second control: Enter > KeyPress > KeyUp"

SO.... editing a textbox there is no way to find out / trap "who disturbed" in case of mouse button pressed... Am I right?

[NeoPa]

This makes clear sense when you consider that hitting a key on the keyboard is positionally non-specific (It is not tied to any area of the screen or form), whereas clicking on a specific button is tied to that button.

Sándor Demeter:
SO.... editing a textbox there is no way to find out / trap "who disturbed" in case of mouse button pressed... Am I right?

In a way yes, but otherwise no.

Access doesn't provide events to give you that information, but Oralloy's suggestion which was expressed most clearly in post #8 is a way to determine the situation and handle it in a reliable way. As he says though, it's a bit of work and involves changing the design somewhat. At the end of the day it's your call how you want to play it, but I see no scope from using events directly.

PS. Sorry for the delay - my service was dead most of yesterday.

[Sándor Demeter]

thank you for the support
Sàndor Demeter

[Rabbit]

Why not just pop up a message box saying that the input is invalid and asking them if they want to leave the invalid data?

[NeoPa]

Because it's not a question about handling a problem, but about properly detecting one.

[Rabbit]

I thought the problem was that given invalid input, they are unable to leave the control. Unless they click cancel to ignore the error?

[NeoPa]

Given invalid input, they sometimes want to leave the control but at other times don't. Determining the difference is proving difficult because the factors involved only become clear once the decision has already been made whether to cancel or not the exiting of the control. The OP would like to use purely event driven logic.

PS. The last response was not intended to sound snappy or critical, just directive (and if that word doesn't exist in this context - adjectival instead of noun - then it does now :-D).

[Rabbit]

Right, they want to sometimes leave the control. But isn't that time chosen by the user? Which is determined by the user clicking the cancel button, signifying that the user would like to ignore validation.

[NeoPa]

Indeed, but that's complicated by the order of processing the various events. See post #13 and those around it for where this was detailed earlier.

[Rabbit]

But all that is because the OP is trying to trap:

A) The user pressing the escape button. Which sets a global variable to True. This global variable is then used to ignore any further validation. This is shown in the code in post #4.

B) The user clicking a cancel button. Which sets the global variable to True. etc.

The problem with B is that the validation code occurs before the click event. Therefore, the code is unable to set the global variable before it does validation. Which means that the user is never able to leave the control unless they put in valid data, clicks the button, and then puts back in the invalid data.

So, what I'm proposing is that the MsgBox that would pop up anyways if the data is invalid, gives them the option to "cancel" validation, either for that control only or from that point forward.

[Sándor Demeter]

Let me clarify the intention.
The control tb_One has a procedure linked to the OnExit event.
It's not necessarily a validation rule.
It could be:
- depending on the value entered, I choose which control is next (tb_Two or tb_Three)
- depending on the value entered, define the RowSource of the next control (eg. cb_Four - a Combo box).

Now. I prepare a cb_One (Command button One) to be clicked with the intention of quitting the edit of tb_One.
However, before the cb_One "feels" the MouseDown event, the OnExit event of tb_One is fired. And I can't verify wether tb_One is being left because the click was on cb_One or elsewhere. That's my problem.

[Rabbit]

Right, so what I'm suggesting is that you use a msgbox in the exit event that asks the user their intention in the event of invalid data. Because if it's correct, then there's no need to "cancel the edit" as you call it. But if it's incorrect, you have to alert the user anyways. So just use that alert to also ask if the user would like to stop editing. That way you don't have to trap button presses and mouse clicks.

[Sándor Demeter]

sorry... it's not about valid / invalid data inserted... the user might have inserted a valid value, though he doesn't want to go ahead, he just wants to stop editing, so he presses the command button cb_One with the intention of leaving the edit... he doesn't care about the value he entered in tb_One and he doesn't want to jump to the next control... he just wants to stop editing...
so... pushing a msgbox under his nose, adviceing him about the valid / invalid value he just entered (when he just wants to stop editing) it doesn't seem a good idea....

[Rabbit]

If he wants to stop editing, does it matter if it jumps him to the next control? He doesn't have to enter anything into that control.

[Sándor Demeter]

well... if I were the user and I would click command button cb_One, I would like to stop editing without jumping forward (or whatever the procedure linked to the OnExit event of tb_One would do)

[Rabbit]

Well, I guess my question is whether or not it matters if it goes to the next control? If they stay in that control and stop editing or if it goes to the next control and they stop editing, in effect it's the same. In both cases, they stop editing.

Unless you're saying the exit code affects the values of other fields. If it's just populating combo boxes, then that will have no effect on the data. But if it actually changes values, then I can see why you want to stop editing in that field.

In that case, the user will just have to use a key stroke to stop editing. Which you have already implemented. However, if, for some reason, you must capture the mouse click, then you will have to implement Oralloy's suggestion in post #8.

[Mihail]

Maybe exist a better way:

Declare a variable at module level i e ExecuteExitEvent As Boolean.

On the text box ENTER event set this variable to TRUE.
On the other hand on the cmdCancel_Click event set the variable to FALSE. On the TEXTBOX_EXIT event, in the first line, verify this variable. If it is FALSE then EXIT SUB.

Hope this is a help for you.
Good luck !

[NeoPa]

Please check back to posts #21 and #13 where the reasons this idea cannot work are discussed.

Don't let me put you off contributing your ideas though Mihail. We always appreciate those with a helpful attitude :-)

[Mihail]

Maybe for you, NeoPa, post 13 is like the sun light.
Now, after I see your post, I read more carefully post 13 and I understood my mistake. I am here to gain help and, if I can, to provide help, not to disturb.
Sorry but I think that I can't avoid all the time that kind of mistakes. So, if you wish to deny my access... that is. Sorry again.

[NeoPa]

I think you misunderstand me Mihail. I was saying the opposite. We welcome and appreciate all attempts to help, regardless of how useful they prove to be.

Even if, in this case, your post didn't prove very helpful, it is still welcomed, as are you.

I'm sorry if I sound stupid repeating myself, but I wanted to be absolutely sure you understand me clearly now.

[Mihail]

Ok.
No problem.
Good luck to all !

The pop-up window require at least 40 characters.
Hope now there are enough :)

[Mihail]

Hi, again !
If I don't misunderstood (again) the really task isn't to avoid EXIT event for the TextBox. The Really task is to restore the value for TextBox if the CANCEL button is pressed.
If THIS IS the task I prepare an example for you:

In a form I have:
- a TextBox control named MyTextBox.
- another TextBox control named txtWitness

Both text boxes have the same CONTROL SOURCE.

- a CommandButton named cmdCancel

And this code:

Option Compare Database
Option Explicit
 
Dim OldTextBoxValue
 
Private Sub MyTextBox_Enter()
    OldTextBoxValue = MyTextBox
End Sub
 
Private Sub cmdCancel_Click()
    MyTextBox = OldTextBoxValue
End Sub

I think do not need comments.

Good luck !