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?
-
-
Because it's not a question about handling a problem, but about properly detecting one.Comment
-
I thought the problem was that given invalid input, they are unable to leave the control. Unless they click cancel to ignore the error?Comment
-
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).Comment
-
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.Comment
-
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.Comment
-
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.Comment
-
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.Comment
-
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.Comment
-
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....Comment
-
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.Comment
-
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)Comment
-
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.Comment
-
Maybe exist a better way:
Declare a variable at module level i e ExecuteExitEven t 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 !Comment
-
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 :-)Comment
Comment