I need a ListBox which will contain several options. I need checkboxes exactly(style), not radio buttons. Is there any way i can allow only 1 checked checkbox at the moment? I'm using MVVM, so i can't just check or uncheck them manually, it's against the rules.
And if i can't make such functionality - is there easy way to style radiobuttons to look like checkboxes?
Aside from a flawed requirement*, the only way to do this is to uncheck all checkboxes, then check the particular indexed checkbox.
Or alternately (cos it does the same thing, but sounds longer), iterate through all the indicated checkboxes and find whichever one is set to true that is not the one you want checked, then set it to false.
flawed requirement: A series of checkboxes indicates to any user that they are allowed to select zero or more items. A series of radiobuttons indicates that they are allowed to select only one. This is something that has been drilled into users since before Windows 3, and that all non-IT will not question. You'll break their mental model, which is worse than looking pretty. Please have management revise this requirement.
HTTH. YMMV.
If you are using MVVM and what to stick to the "rules" then your ViewModel should have a property to which the checkboxes bind. Its the up to code in the ViewModel to ensure that state of this property is correct.
So code in the ViewModel where one property gets set to true may need hunt through a collection to find similar items whose matching property needs to be forced to false. The View then simply reflects the current state of the ViewModel.
Well, in the end, i used this solution
Related
Is there a way that I could partially select a list item with sap.m.ListBase mode set as MultiSelect?
Something like this for some of the entries in the list:
https://sdk.openui5.org/entity/sap.m.CheckBox/sample/sap.m.sample.CheckBoxTriState
In the official UI5 API reference for sap.m.Checkbox, there's the property partiallySelected. But for the sap.m.ListBase, I couldn't find anything.
To anyone who faces this problem, I found a solution,
So earlier I was relying on the checkboxes provided by the list's MultiSelect mode and then displaying the items as StandardListItem but I later replaced it with CustomListItem and in it, added my own checkboxes, in which I could set the partially selected property.
I hope this helps :)
I don't think the tri-state makes much sense in combination of sap.m.ListBase and mode="MultiSelect". According to the SAP Fiori Design Guideline checkbox sections regarding "Tri-State":
Usage
[...]
You want to group multiple suboptions under a parent option, and require an intermediate selection state (tri-state). The tri-state indicates that some (but not all) suboptions are selected.
[...]
The main purpose of this state is to represent the mixed selection states of dependent input fields. If some (but not all) of the dependent fields are selected, the checkbox shows a partially selected state. This is only a visual state and can’t be achieved by a direct user interaction.
Unless the list control is of type sap.m.Tree, displaying tri-state checkboxes in sap.m.ListItemBase without any suboptions deviates from common UX patterns and thus might be confusing for end users. I'd suggest reviewing SAP Fiori Design Guidelines (or other design guidelines in case of freestyle) and re-evaluating whether checkbox is really the correct UI element for the intended interaction design.
Basically, I have a listview inside my form. In order to make the process of selecting the different items in the listview quicker, i have to add a "select all items" checkbox.
For Each lvItem As ListViewItem In Me.lvwDatos.Items
lvItem .Checked = True
Next
That's about it, very simple. Once i click on the select all checkbox, i can see clearly how all the elements go into checked state. However, on the next step, when i want to loop through the selected items in my code and do whatever tasks should be applied to them, i'm finding that ALL elements are unchecked. What's making them loose their state?
Ok, nevermind, i found the problem...that's how it is supposed to be, there's no problem in the listview, it's just the chain of events that were taking place that broke it all...legazy code, as usual...
This is why I have designed Better ListView component which have this behavior fixed (and many other quirks of .NET ListView).
There is also a free Better ListView Express, if you are interested.
The checked item collection is maintained separately and you always get its actual state.
Winforms question:
Better design to have 1 control, say a dropDownList, conditionally bind to multiple datasources or multiple dropDownLists with each their own datasource?
You'd use if then logic to select which datasource to connect to with the first option. You'd use if then logic to select which databound control to enable and show() with the second option.
I'd go with the first one, unless the dropdowns controls themselves were different. It might not be just databinding that changed, colours, styles, event handlers...
You could deal with them as well of course, but at waht point does it beome too messy.
There is one thing though, if you do all the controls, position them in code when you make them visible, don't lay them one on top of the other in the designer so you don't have to, terrible habit that.
I'm using PRISM (and thus the MVVM pattern). I've got a complex DateTime picker view with radio buttons.
The user can pick today, yesterday, a date, a week of a year, etc. I use radio buttons for the different choices.
What's the best way to do that in MVVM?
I really can't think of a clean way. I could create lots of custom behaviors to add to each item to track them but it doesn't seem maintainable.
I'm going to put some code-behind but I really don;t like that and to me it breaks the MVVM principle (put everything in the XAML).
Does anyone have a better idea on how to go about that?
Keep the RadioButtons, add an enum type to your VM that can return things like "Today" "Yesterday" or "Tomorrow." On the UI side create a ValueConverter that takes a parameter like "Tomorrow" and compares it with the bound value on VM, then returns the bool? needed by IsChecked.
Put it in code behind.
The M-V-VM pattern is not "put everything in xaml" it's "separate concerns". Your VM wants a DateTime right? In which case it doesn't care how that DateTime is being chosen it just needs a DateTime.
Putting View logic in the ViewModel isn't a good idea as you're now giving the VM knowledge about the workings of the View. The flow is meant to be View knows about the ViewModel which knows about the Model. The reverse is not normally true. (As with all things computer related there is always exceptions)
Hope this helps.
How about a ComboBox instead of the RadioButtons presenting a list of TimeOffset (custom class) bound to your ViewModel, with a corresponding SelectedTimeOffest property.
If you need to display extra information depending on the type of TimeOffset, e.g. a WeekOffset (subclass of TimeOfset) with a WeekCount property, have a content control with several DataTemplates customized by the type of TimeOFfset.
Just an idea...
you could create a enum, bind the values of the enum to a listbox, retemplate the ListboxItems
this post is using silverlight, but something similar should work
http://leeontech.wordpress.com/2009/03/18/creating-radiobuttonlist/
The ViewModel is designed to present the model in a way the view can consume.
In this case, you could have a boolean property for each button in the VM, and when a button updates it just sets all the other properties to false. Then in your View you can bind each properties IsChecked to the corresponding property in the ViewModel.
Also, be aware there is currently a bug in binding radio buttons in WPF. Here's a potential solution.
I have a question regarding a ComboBox in silverlight and it's selected item.
I would like to determine what triggered the SelectionChangedEvent, was it the user selecting a new item in the list or was it programatically set?
While ideally I would like to solve this using the CommandPattern (I am essentially using a modified RelayCommand (http://joshsmithonwpf.wordpress.com/2008/11/17/emulating-icommandsource-in-silverlight-2/). I am open to other suggestions.
I have also played around with the SelectionChangedEventArgs, which has an OriginalSource property, which upon first inspection may appear to help, however it is null (regardless of the manner in which the item was selected.)
Any ideas, other than setting an internal flag? :)
Thanks
Unfortunately this is a tough thing to determine, since the framework works pretty hard to simply bubble up any changes or user events in this situation as that selection changed event.
If you really need to, you could write a simple ComboBoxWrapper that is effectively the flag you're talking about - so you could derive from ComboBox, try overriding or hiding the CLR setter for SelectedItem, and then maintain state that way.
Any particular scenario in use here? There may be another way to approach a solution.