I have a strange problem with a listbox. I added only the listbox and a button which adds items to the listbox. If I click an item in the listbox it seems to have some strange multi selection mode on or something... i recorded a short screen cast, see for your self:
http://www.youtube.com/watch?v=zV4424ipNEA
any ideas whats wrong?
That is a known issue, as all those strings are the same the selection gets confused because they all are essentially the same object. If you create two identical strings in .NET it does not necessarily create a new one but may reuse the first instance, i am not an expert on this though.
Either wrap the strings in a class (make them the Content of a ListBoxItem for example) or make sure the values are unique.
Related
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'm interested in what is the best way to implement the removal of related set of UI elements.
This is what I'm working on: I have a Grid embedded within a verticle Scrollviewer. The user can add multiple Listboxes to this Grid during runtime via a button click. Each ListBox, when added, will also result in the addition of the correct number of Grid Rowdefinitions and a Gridsplitter to allow the resizing of each Listbox. This parts works fine.
The trick is this -- the user also has the option of closing a Listbox. When they do this, I will need to remove the corresponding Rowdefinitions and Gridsplitter that "belongs" to the closing Listbox.
Via iteration through Grid.Children and Grid.Rowdefinitions, I could somewhat easily figure out which Rowdefinitions and Gridsplitters to remove. But I'm wondering if there is a better way to handle this. Perhaps by grouping these elements together in a collection and simply removing this collection in one fell swoop? No idea how to do this, though.
Any ideas or suggestions are greatly appreciated!
I'm not aware of an obvious or simple way to associate them within the visual/logical tree, but you could certainly use an associative array (Dictionary<T, U>) that's keyed off of the element you're removing with the contents as the other items that need to be removed.
I think this is essentially what you described.
Anything more clever wouldn't be worth the additional complexity, I think, unless you had a specific need for it. :)
I've written a custom panel which displays its children docked either vertically or horizontally, separated by moving splitters in between. Since the Grid panel offers much of this functionality out-of-the-box, I just inherited from it.
To create the layout, upon Loaded is fired I do the following:
1) Read how many children it has and create the appropiate number of rows/colums.
2) Position every existing children in the corresponding row/colum.
3) Create, position and add a GridSplitter for every child.
This approach looks and works fine, but it opens the door to a lot of problems:
Since it's added a GridSplitter for each child, there are twice the number of expected children. If someone added 3 elements to it, Children.Count would return 6.
User could insert/remove things at the wrong place.
It just throws an exception when this Grid is used as the ItemsPanel for an ItemsControl, since in this case WPF (not Silverlight) does not allow direct children manipulation.
These 3 cases are the ones I've already tested, but I'm pretty sure a lot more would arise depending on what the user does with it.
As it turns out, this class must be regarded as 'implementation details', so the real question is, what control should I put in front of the user?
It sounds like it should be a Panel, but I can't control the Children property since it's not virtual, and there's also the ItemsControl which I think could be a good candidate, but I really don't know.
I'd much appreciate any kind of advice or some directions to do this the right way.
Thanks in advance.
You see using just grid you leave yourself with an imperative way of adding items only. As in
myCustomGrid1.AddMyItem(***), Grids simply don't have ItemsSource property. ItemsControls do - so if you need support for declarative items sources i.e. myControl.ItemsSource = {Binding ...} you're going to derive your control from ItemsControl. This is not a two liner - making your ItemsPanel Children writable is a big challange - there's no simple way of doing that.
This is all about a small thing overlooked during the Grid's design - splitters shouldn't have been added to Children collection, as Children are visulaizations of your BOs while spliiters are just formatting elements.
Here's what I would do.
Forget about ItemsSource & items altogether - it's aint worht the hassle. The only way to add/remove items to your control will be AddResiazableItem/RemoveResizbleItem. Calls will add items and splitter (for the middle items), extend the number of rows/cols of your grid depeneding on its orientation, set Grid.Row/Grid.Column attached properties for your visual children. You can keep your actual objects internally to support Orientation change.
If at any stage you'll want to bind your control to IEnumerable source - just create an attached behavior, which will iterate through the items and call AddResiazableItem within a loop.
Cheers.
P.S. To moderators - the editor seems to get broken, lads. I cant see the second item.
P.S.S. Got it fixed after a few tries.
I am eager to find some solid (free, Open Source, or tutorial/example) code to make a WPF Combobox do autocomlete/autofilter as the user types. But everything I've tried so far has had some sort of problem...
A Reusable WPF Autocomplete TextBox came close, but I can't get it to work with more than one filter (more info here).
WPF autocomplete textbox/combobox doesn't work for me because it inherits from UserControl, and thus doesn't support the DataTemplates I need (for showing/selecting the value of one property for an object with multiple properties).
Automatically Filtering a ComboBox in WPF didn't work because it doesn't seem to ever find the EditableTextBox portion of the inherited ComboBox code (via (TextBox)base.GetTemplateChild("PART_EditableTextBox") which seems to always returns null).
Building a Filtered ComboBox for WPF just gets stuck in a refresh loop then overflows the stack after I type just a few letters.
Other things I've considered:
I know that Windows Forms' Combobox control has AutoCompleteMode and I could embed it in WPF, but I can't imagine it would play very well with my WPF data bindings.
Perhaps it is too complex and I need to simplify, maybe by building one-dimensional (single-property) ObservableCollections for the ComboBoxen... However, the challenge of applying multiple filters (one set by another control's value, and one from what the user is typing) to multiple controls using different views of the same DataSet would require a ridiculous amount of processing power to destroy and rebuild the list every time the user types a character!
So... I'm at wit's end. Any suggestions?
If your Combobox has some data source attached to it ,
just make
1-IsTextSearchEnabled = true.
2-IsEditable = true.
you are good to go
Try this one:
http://blogs.windowsclient.net/dragonz/archive/2010/02/23/autocomplete-textbox-control-for-wpf.aspx
I have a following requirement for a very complex UI. (Complex here means there are lot of controls in the form [approximately 100]). I am using MVVM (if my problem requires it to slightly go away from MVVM I am ok with it)
My question is for Editable ComboBox and TextBox. But I would say I like to hear a common algorithm which will fit all controls.
Requirement 1 : The user edits the content and goes to next control, the color of the control/text should become red.
Requirement 2 : When the user comes back to the previously edited control and enters the value which was initially present, the color of the control/text should become back to black.
I know the requirement is tough and I have been breaking my head to design a generic algorithm using which I can store the previous value and call a function to change the color of control.
To just give you all an idea, --> I tried storing 2 properties for every TextBox like Default_Text and Text. But since the number of properties are huge, the memory footprint is very huge. Also maintaining so many properties is very tough.
--> I tried adding a Dictionary to every ViewModel to store what values have got changed. But here the problem I faced was giving unique keys to all the controls in my application, which is not very helpful
--> I had even thought and tried about subclassing controls like TextBox, ComboBox and overriding some methods to suit my requirement, but sadly I failed miserabley when I started adding validations and all.
So here I am stuck with designing a generic WPF property system/algorithm to handle all undo redo functionality, changing styles of controls,etc!!!
It will be really great if you experts can guide me in right direction and also help me in developing such an algorithm/system. A sample illustration will be nice though!!!
I found an answer to the above problem. I used attached behavior for this. More details on this link Function call from XAML from StackOverFlow.
When I databind, I store the initial value of the DataBound variable in the Tag property by using Binding=OneWay. Then I have written a attached behaviour for LostFocus event. Whenever the user enters a control and then goes to other control, it fires LostFocus event and calls my attached behaviour. In this, I check whether the value is equal to the value in Tag. If it is same, I display in black else I display in red.
Attached Behaviour rocks in WPF. I can achieve anything from that cleanly without code cluttering!!!!
Another alternative is to use some "dirty" tracking in your models (or viewmodels) and bind to a properties isdirty (and convert it to a color).