I have two tabitems. User will enter some data and save it on the first tab. The second tab lists the saved data. What I need is when the user select the second tab before saving data in first tab a confirmation message box with Yes, No and Cancel should be shown. If the user clicks Yes button the data should be saved and go to the second tab. If he hits No, the data need not to be saved and finally if Cancel is hit the tab will retain with all entered data. How can i make this?
To keep things simple you can do the follwing in the Code Behind file.
I'd create a Model class of the data you want to display and edit in the WPF Control. Make the Model implement the INotifyPropertyChanged and IEditableObject interfaces.
INotifyPropertyChanged will allow you to Bind to the Model.
IEditableObject will allow you to provide Edit, Save and Cancel functionality.
The TabControl has a SelectionChanged Event you can handle, that will allow you to detect when the user changes tabs, in this handler you can use System.Windows.MessageBox to ask the user to save etc, System.Windows.MessageBox.Show() returns a MessageBoxResult Object you can use to detirmine what button the user clicked and perform the appropiate action.
This is not a geat way to do things, but it keeps things simple, you may want to look into some WPF design Patterns to help with Code Manageability.
If you need anything explained further, just ask.
Although I disagree with the way you interrupt the user's flow from tab to tab I'm going to humor you and answer the question:
You'll need two things to get this done:
The event that occurs when a tab was clicked
The previous tab that was selected (the one you came from)
The first item:
The tab control has a Click method that you can subscribe to:
Click=”MyTabButton_Click”
The second item:
This part you'll have to do manually. You can set a variable in the click event which contains what tab was last selected. Once this is set you can check a variable (which you previously set) as to what tab was previously selected. You can then do all your validation.
Delphi's TPageControl has an OnChanging event with an "AllowChange" parameter. I guess there is something similar in WPF.
Related
Once I successfully validate user data in a TextBox (using TextChanged EventHandler), I'd like to programmatically tab to the next input control. I know I could hard code the name and do
Score2.Focus(Windows.UI.Xaml.FocusState.Keyboard);
but I've got 20 TextBox controls on the page page and I'd like to use the same EventHandler for all of them.
While it may be possible (iterate through the page's control inspecting their tab order and selecting the appopriate next control), I would recommend against it. It will irritate your user if they leave a text box to go back and correct a previous field but your app decides it knows better and gives focus to another field.
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()
I'm developing an ASP.NET web application with AJAX.
I have a page where the user can edit some information: it has a list of item, the user select one item, click on Edit button and then edit item's name and item's description on two textboxes.
If user click on another item since he doesn't save his changes, he can click on edit button to edit this new item.
I want to check if there is some data on textboxes and ask to the user if he wants to lose their changes before loading the data of the new item.
How can I do that?
Thank you.
There are four ways that I can think of to handle this:
Always save the changes (auto save). We've eliminated almost all save buttons from forms and just always auto save the data based on user feedback.
Always prompt to save changes; i.e. assume that if the form is in edit mode then there are changes.
Hook every control's change event and toggle a boolean if any control fires its change event; prompt the user if it's true.
The hardest (and arguably best) method is to actually compare the previous values to the current values and only prompt if they're different.
The method you select depends on the application and user expectations.
In my application I have dropdown list with several items. I'd like to show a context menu when the user clicks the right mouse button on a dropdown item. Is this possible? And if it is possible, how?
It is possible but not easy. The ComboBox dropdown is a native ListBox that is created on-the-fly. To get the handle of that list box, you have to send the CB_GETCOMBOBOXINFO message in the DropDown event. Check my answer in this thread to find out how to do this.
The iceberg that is likely to sink that Titanic is that the dropdown automatically closes as soon as it loses focus. Which will happen as soon as you display the context menu. Nothing you can do about that.
Consider a different approach, you could use an actual ListBox that you make visible when the user clicks a glyph that looks like an arrow next a TextBox.
Not possible easily. No hover or right-click event messages are being sent when the combobox is expanded.
You can see this is the case when using Spy++.
I think the easiest would be to change to a listbox if your scenario allows you to do that.
As Wim said in his post, there's not a direct way to do this because the messages you want aren't fired.
As a comprise, you could try setting DropdownStyle=Simple; on the Combo and
shrink the scroll region to show a single line:
http://img34.imageshack.us/img34/1695/49557147.jpg
If you assign the Combo a context menu, it will open when the scroll region is right-clicked. You'd probably have to figure out what item was right-clicked. But as other have said, this doesn't sound like a standard Windows way or an intuitive use.
Or how about a modal dialog that you could bring up from the Combo's context menu? On the dialog, you could have a list that the user could select from and a Delete button to delete the selected item(s).
Since MenuItem doesn't have a ContextMenu property it isn't as easy as it is with many other controls. You'll probably need to capture the right-click event and then position and show the context menu manually.
Two caveats though:
The combobox list will close when the
list loses focus, so it may close
when the context menu is shown
leaving the user unclear as to what
they clicked on (not 100% sure on
this, since I haven't written the
code to test.)
More importantly though I would argue
that this is a poor UI choice, I
can't think of any real world
applications I've used that have
context menus on menu items, so it
wouldn't be very discoverable for the
end user. Plus context menus should
be just for quick access, they
shouldn't be the only way to access
functionality. Are you going to be
able to expose these functions
through other means as well as the right-click menu?
You could do it manually, by capturing the event on the form, but consider making a nested menu instead. If your combobox items have menus of their own, combobox probably isn't the right choice.
For those asking "Why?" or saying they've never seen a combobox with a contextmenu; Look at any web browser's favorites dropdown. You can right click and delete, edit, or go to the entry in current tab, new tab, or new window.
I also could not get an actual contextmenustrip to show, so I made a menu with a small borderless form and call with:
Private Sub FavoritesBar_SelectedIndexChanged(sender As System.Object, e As System.EventArgs) Handles FavoritesBar.SelectedIndexChanged
FavIndex = FavoritesBar.SelectedIndex 'FavIndex is declared as a public string.
Dim Loc As Point = New Point(MousePosition)
FavMenu.Location = Loc
FavMenu.ShowDialog()
End Sub
With a homemade contextmenu, be sure to add "me.close" at the end of each sub as well as the me.mouseleave event.