Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Determining which button was pressed ?

Status
Not open for further replies.

aprobe

Programmer
Dec 4, 2003
36
NZ
I have a form with a text box, an ok button and a cancel button on. When I exit the text box I perform some validation and either stay on the text box or populate some other fields and exit.

This works fine if I put the code in the textbox's 'Leave' event or 'validating' event. The problem is if the user enters invalid information I display an error message and stay on the same field. I can close the form by pressing the 'X' button but I cannot close the form by pressing my 'Cancel' button as the textbox's event is processed first.

Is there any way I can determine in my validation routine which button caused the 'validating' event to be fired. i.e. which field will next receive the focus.

What I want to do is not perform the validation is the 'Cancel' button is pressed.
 
You can do the validation in the event click of the ok button. This is more common way in dialogs.
 
That's no good for me. I need to lookup information and populate other fields before proceeding to the next field.
 
If the click event of the cancel button is fired before the validating (or another event, maybe MouseDown), you can set a flag there and check it in the validating event.
 
That's true, but it isn't fired before or else I could have done what you suggested.
 
Catch all events of the cancel button and put a breakpoint in each. That's how you can find out which event is fired first.
Another solution: catch the event MouseUp in the form context (You need to set the KeyPreview property of the form to true). In this event find out if the location of the click is within the cancel button and raise the flag. In the validation event check if the flag is raised and set it to false.
 
Just my two cents, but as a user I would dislike the behaviour of your app. I need to be able to leave a textbox even if my entered value is not correct yet! Just an example:
I write some text, then I want to copy and paste something and then write text again. This is not possible with the behaviour you explained!

I would recommend just colouring invalid Information, or diplaying a message box or something like that.

But again thats just my Opinion!

Stephan
 
Whilst I might agree with you for a web application I don't think this is very professional for a normal windows app. For example I might be completing an order form, entering the customer account number at the beginning. The user would expect to see the account details like the address etc before getting to the end of the form and pressing the OK/Accept button, only to find the details entered are all crap!

I have managed to get the problem resolved for the time being by setting and clearing a flag when the user 'Enters' and 'Leaves' the Cancel button. I would have thought there was some property somewhere to record the next control to receive focus. After all this must be recorded somewhere, it's just a matter as to whether or not this is exposed to the developer?

 
I see what you are saying, but I think Windows just detects that a mouse click occurred outside of the text box control and thus it has lost focus. I don't think it gets around to processing what the mouse did click until after all the events for the text control have run.

It seems to me you've already found the most proper way to deal with it by utilizing the mouse's location via 'Enters' and 'Leaves' events over the Cancel button. But I could be wrong, sometimes it would be nice to have a little more under-the-hood exposure in .NET.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top