How do I get 2 synchronized comboboxes so that changing the index of the one automatically changes the other one.
I have no idea what language you are using, but for something like .NET you would go into the SelectedIndexChanged event of the comboboxes and in there put:
Combobox1.SelectedIndex = ComboBox2.SelectedIndex and vice versa for the other one.
Note: You want to make sure that your boxes have the AutoPostback property set to True.
This depends on the framework/language/toolkit/platform, and many other features, but the basic idea is the same:
Just listen in for the "selected item changed" event/signal/etc on both combo boxes, and when one changes, set the other appropriately.
Related
I have a Tcl/Tk program. In it I have a combobox, like so:
set cb [ttk::combobox .cb -state readonly -textvariable selection -postcommand [list choices .cb]]
The proc choices runs when the combobox posts, which is what I want. My question is, how do I detect when the combobox unposts?
I've tried both binding on <<ComboboxSelected>> and setting a variable trace on selection. The problem with each is that they only fire when the user actually changes the selection. I need some way to always detect when the combobox unposts.
Thanks!
edit
What I'm trying to accomplish: When the combobox posts it presents the user with a list of options. I don't expect the user to know what the options mean, therefor I am highlighting the options visually in a different area of my program. I have this highlighting triggering and working well with -postcommand. The issue is to know when to turn the highlighting back off.
<<ComboboxSelected>> doesn't fire if the user doesn't change the selected value.
<Leave> and <FocusOut> fire too soon (e.g. as soon as the box posts).
The combobox's popdown is actually its own nest of windows, and if your combobox is called .cb then the popdown has the imaginative name .cb.popdown (note that this implementation and is not guaranteed). If you add a binding to that widget's <Unmap> event you'll get to see the unposting; <Unmap> events are exactly the notifications sent when a window ceases to be displayed in the virtual desktop layer sense (as opposed to just ceasing to be visible, say because there's another window on top; there's events for that too, but they're not cross-platform).
The tricky bits:
The popdown is usually created when needed, i.e., the first time it appears. You need the window to exist (but not necessarily be visible) before you bind to it. You can get the handle of the popdown widget with ttk::combobox::PopdownWindow, which will make the widget if it doesn't already exist. (It's part of the implementation, but it is more likely to be stable than the name.)
set popdown [ttk::combobox::PopdownWindow .cb]
bind $popdown <Unmap> {yourCallback %W}
It is possible to dig around within the internal arrangement of the popdown, but I don't recommend it; it's much more likely to change without warning.
Binding to the toplevel has the usual issues with events also being delivered for subwindows. Your callback should check that the event it has been given is actually for the toplevel:
proc yourCallback {w} {
if {$w ne [winfo toplevel $w]} { return }
# The rest of your code here...
}
The window name of the listbox used by ttk::combobox is:
set popdown [ttk::combobox::PopdownWindow .combobox].f.l
I believe this is what you need.
bind <Leave> $popdown mycommand
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.
I have large collection of statuses(bool) that are reached by key (address)
the visual should display each status as different control (for example checkboxes, buttons, radios , etc) - each control is provided with the address of the status it will display
for example
button1 <- status[55]
checkbox1 <- status[81]
..
etc
my question is if i put INotifyPropertyChanged on whole indexer(if i do it with indexer) - if one value changes does it update all the controls or only the changed one..
I want only one status change to update only one control - not all of them. Is there a way doing this?
It will update all, in Silverlight you could construct a notification that only updates one index. I cannot think of any solution which would let you keep that structure, if you map everything to objects with key and value you could internally notify of value changes...
In WPF 3.5, is there a property of the combo box will allow the user to undo the selection they've made?
Code
If you look to a way to reset the selection from code (you wrote a property), try the following:
cboYourCombo.SelectedIndex=-1
or
cboYourCombo.SelectedItem=null;
Keyboard Shortcut
If you look for a keyboard shortcut to reset, I've never seen. But if you want, you can do it on your own, it's probably easy:
Attach an EventHandler to the PreviewKeyDown-event of your combobox (or register a general event-handler that works for all comboboxes in your window/app), check the key and if its the key you want to reset, use the code above to reset the selection. Please note, in the PreviewKeyDown-event you can also check for special-keys such as the control-key.
Provide an empty Value
However I think, better would be to add an empty entry and then preselect this empty value. If the user has changed the selection and wants to reset, he can select the empty value. Otherwise you change the standard UI-behaviour and not all people like this.
What do you mean by "undo"? Do you mean something like CTRL+Z (or an undo button), or something like CANCEL? Implementing true undo/ctrl+z on a combo box is something very few applications do, and it will surprise the user. This is a very bad idea, unless you have a very good reason.
If you have a very good reason to go against the design of most windows apps, you can add a handler for SelectionChanged, and implement your own history. Then, if the user either uses a keydown (ctrl+z), or clicks an "undo" button, you can set the selection yourself.
Alternately, if you don't really want an UNDO feature, and actually want a CANCEL feature (a common feature in UI apps), then you shouldn't worry about each control individually. Just keep a set of stored settings (in some custom class), and set all the controls back to the values that were stored. In the case of a combo box, you'd want to set the Selection property.
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