I have some requirements in how a DateTimePicker selects a date: it basically needs to close it's parent form when a date is selected. I was originally thinking I could just use the ValueChanged event to basically capture that and close the form; however, this doesn't work because using the arrow keys for navigation is firing a value changed every time.
What I need is either:
a.) if the user hits ENTER after using arrow keys to select a date or
or
b.) if the user clicks on a date
occurs, it should close the form.
My first thought was to ditch trying to use the ValueChanged event handler and instead use the CloseUp handler, but this doesn't work because CloseUp gets fired if the user clicks anywhere around (or behind) the form.
Click events on dates do not seem to work either; and it seems like I can only rely on ValueChanged (somehow).
Is this doable? Or are the strict requirements preventing this from being possible.
Related
Using c# winforms vs2008
I'm using a TabControl on a form. Each tab has a different set of input fields. Some of those fields has to be completed. Such as Username. Multiple users will use the same PC, so a the username must remain static. I have a leave event on the require fields which triggers when the textbox loses focus to check if a value was added. In the case of Username, a popup would then presents possible values. That works pretty awesome to ensure accuracy and speed. To problem comes in when the user clicks on another tab, the textbox leave event triggers. How can I prevent the leave_event code from running if the focus changes to a control not on the current Tab?
I have tried different event handlers, but the leave event seem to occur first. I tried textbox validating event handler, but also no success. I tried adding a If-statement in front of the code to check the tab number, or tabcontrol state - no joy - as before anything else changes, the leave event fires.
The only remaining thing I can think of is to loop through all the controls on the tab to check if they have focus, but that just feels messy.
Any other suggestions?
I have found a partial solution. Using a Mouse_Enter and _Leave event on the tab, I set a flag to determine whether the mouse was clicked in the form or outside. If the flag is set to false, the leave event dont run. This will not solve short cut key presses though. But that I can handle later.
I have the next situation:
there is a client app with a Form
the Form contains a few TabControl's
there are different controls on TabPage's of TabControl's
when the user clicks on any control, I need to activate the TabPage that is a parent of a control. For that I use a TabPage Enter event
when the TabPage gets activated, I need to make request to the server app, and I put focus to a hidden TextBox to disable UI
The problem is, when I click on a Button on another TabPage, in TabPage.Enter event handler I take focus to my hidden TextBox, and it seems like Button click event doesn't have enough time to be processed. When I put timer and handle TabPage.Enter event after 100 ms, the Button click event seems to be fired well. Same thing happens to all the controls: CheckBox doesn't get checked, RadioButton too. I wouldn't like to use timer, as that is not a stable solution.
Any ideas how could I make TabPage to process all mouse events before I take focus to hidden TextBox? I tried to use Application.DoEvents(), but that didn't help.
You are using a wrong event for a wrong control for what you are trying to do.
Enter event for TabPage is going to be fired when that page becomes an active control of the current form which might not happen under certain conditions. Instead, you need to use Selecting or Selected event of TabControl, depending on whether you want to cancel switching to a different tab or not (see TabControlCancelEventArgs parameter of Selecting event). In your case, Selecting event would be more appropriate since it won't allow switching to a selected tab until event is complete (unless you're doing an asynchronous request to the server). Additionally, you may no longer need to use the hidden TextBox.
UPDATE
Regarding comments to OP, when you have 2 (or more) TabControls on a form and you want to get notified when you press a button in any tab of a different TabControl, you can use Enter event for TabControl. Use a global variable to store which TabControl was activated in the Enter event and then send server request for a currently active tab of that activate TabControl.
If this doesn't work for your scenario, then you need to carefully examine your workflow and see if it can be improved in relation to what you want to accomplish.
I have a form where there is group of radio controls and some with textbox.
If the cursor is on textbox and i try switching the cursor to a different radio button, i should be able to identify the last active control( in this case.. the textbox) and do some validation.
The LostFocus() event of textbox pops up message indicating that "this item should be filled in..".
But if i want to go with a different radiobutton option in the same group, i dont want this message popping unnecessarily.
How do i avoid that?
The TextBox has Validating and Validated events-- you should use those instead of the LostFocus event. In the case of Validating, you can stop the user from leaving the TextBox if the criteria isn't correct. If you must use "something" like LostFocus, use the Leave event instead.
There is no "Last Active Control" type function. You would have to track that yourself by setting a variable on the Enter event of those controls.
That will lead to an ugly mess to maintain in my opinion. Validate at the form level is probably the best choice for the end user.
I am recently working on windows forms with visual C# and I have a bunch of radio buttons grouped together.
I needed to call some methods if the radio button is clicked and also do some validation.
So I have two methods,
public void doSomeStuff()
public bool valRadioButton1()
I can call doSomeStuff() in the click event and the latter in the validating event of the radiobutton but I could also just call both in either the click event or the validating event.
My question is that are there any advantages and disadvantages as to what event I would use to call these? Or is there any particular way is more efficient. Right now it seems that both events would do the exact same thing so why use one or another or both.
Radio buttons are kind of strange in combination with the conventional validation. The validating event seems to be designed to allow you to validate a value once when the user is done entering a value instead of every time the value changes as the user is entering it. This makes sense for a textbox where you want to look at the completed text instead of after each character that the user types. But it's a little more obscure for radio buttons. In fact I think you should generally avoid the validating event of radio buttons and instead use the validating event of the container (radio buttons should always be in an embedded container). This allows a keyboard user to select/move through different options to arrive at the one they want without repeated validations as they move through the options. Then when they move focus out of the group box (or whatever container you used), you can validate the whole option group at once. This behavior is more consistent, then, with that of other controls' validation. In fact I see very little purpose to using the validating event on individual radio buttons. The only reason I see is if you want to cancel the user's new selection without causing extra click events. But be aware that when no radio button is selected and the user first clicks on one, no validating event will occur! No radio button lost focus and validating events only occur when a control loses focus. So this is why I think you should just avoid the validating event on radio buttons and just use the validating event of the container or the click event of a radio button.
Also, I think if you want to be nice to keyboard users, you should keep the validation logic separate from the click logic and use the events appropriately. Things like enabling controls based on which option is selected would belong in the click event of a radio button, but error and warning messages about the currently selected option should go in the validating event of the container.
Edit: You asked specifically about when one event occurs and not the other. I would add this information in response to that:
Validate will be called without calling click if the code is what causes the selected radio button to change, assuming focus then passes to the radio button (or container, if you are using the container's validate event).
Click will be called without (or should I say before) calling validate if no radio button was selected and the user then clicks on one (validate only occurs when the control loses focus). Validate will eventually occur for the clicked option, though.
Click will be called without (or should I say before) calling validate if your validate handler is not linked to the specific option that was previously selected or its container. It will be called for the option that is now selected (and the container) when this option (or the container) loses focus, though.
Click could be called without validate being called if your code that looks at the value doesn't require the selected option to lose focus before looking at it.
The validation event exist for when a controls value has changes, this is decoupled from how the controls value was changed. Was it changed because a datasource was refreshed, was it changed by an end user, was it changed on a timer? Doesn't matter!
I would use the validating event to evaluate if something is valid. Even if you know that there is "no way ever that it could happen any other way".
I have a TabControl with two tabs. One tab has a list of stores and the other has a list of employees. On the store tab I have a button that displays all employees of the store; to do that, I want to switch to the other tab and invoke a showEmployeesFromStore(store_id store) method from that tab's User Control. How would I do that?
You've got the wrong mental model. Just because the user control isn't visible on the TabControl doesn't mean that the code is invisible as well. Just call the control's method in your code, it needs to be public of course. Then change the tab control's SelectedIndex property to switch the active tab page.
The button should not be part of the 1st user control. Actually it is better not to use a button but to just trigger an event when the user selects another store.
I would expose an event on the store user control for SelectedStoreChanged or something to that effect. Pass back the newly selected store_id in the event delegate.
Subscribe to that event with your form. When the event fires, it is the form's job to decide with to do with that information. In this case, have it pull out the store_id from the store UserControl's SelectedStoreChanged event and pass it in to EmployeeUserControl.showEmployeesFromStore(store_id store)
Keep your controls ignorant of each other. Let the owner of the controls decide how to react to whatever events are raised by the controls. You'll sleep better with dreams of increased usability, better separation of subject areas, and more fewer working weekends due to untangling odd control flow... ;o)
Just realized I missed a detail. The button you're talking about should be on the form itself and not any of the user controls, assuming you don't want it to just update in real time using eventing described above. On button click, the form should go check StoreUserControl.SelectedStoreID() and pass the result to EmployeeUserControl.showEmployeesFromStore()