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
Related
I've been creating an inspection form using WPF and I need a place where users can type an unknown amount of comments (hence why I'm not using textboxes). In my WinForms version of this application, I used a DataGridView and I could enter in as much information as I wanted to. I'm looking to do the same with a DataGrid or an equivalent control in WPF.
WinForms Example
I need to be able to do the same thing in WPF but I can't seem to add any rows in the DataGrid. On top of that, when I try to check CanUserAddRows it unchecks it immediatly.
So I checked out Vincent Sigal's blog post about this issue. He mentions something interesting:
... but beware of CanUserAddRows and CanUserDeleteRows as they can appear a little magical. Their values are coerced based on other properties such as DataGrid.IsReadOnly, DataGrid.IsEnabled, IEditableCollectionView.CanAddNew, and IEditableCollectionView.CanRemove. So this is another thing to watch out for when editing. If you run into a situation where you set CanUserAddRows or CanUserDeleteRows to true but it is changed to false automatically, check that the conditions below are met.
I verified this and my DataGrid is not read-only and it is enabled. Although, I have no idea where to find the IEditableCollectionView.CanAddNew and IEditableCollectionView.CanRemove ...
I don't think my situation should require a binding event on the DataGrid since the user is supposed to enter his comments directly into the DataGrid ... Is what I'm trying to do even possible? Perhaps I should use a different control?
I have to admit that I stopped reading through your question after the first paragraph, so please forgive me if I have understood you wrong... but if you just want to enter multi line text into a TextBox in WPF, you can do it by setting a couple of properties on it:
<TextBox TextWrapping="Wrap" AcceptsReturn="True" />
For a DataGrid, you can set these properties in the DataGridTextColumn.ElementStyle and/or DataGridTextColumn.EditingElementStyle as the WPF DataGridTextColumn multi-line input post shows quite nicely.
Please let me know if I did misunderstand you.
UPDATE >>>
Ok, so I came back to read the rest of your question... answering without reading the question can be risky business on this site. It's just as well that I did too, as I see you also want to know how to use the DataGrid.
I have to start by saying... take a deep breath... WPF is very different to WinForms... very different. In WPF we manipulate data rather than UI objects, so to add a new row actually means adding a new item to a collection. You can find a complete working example on the DataGrid Class page on MSDN.
Please also view the WPF DataGrid Control page on WPF Tutorial.NET for more examples. WPF has a lot to take in for new comers and can be quite bewildering, but it's well worth the trouble when you get into it.
I've got a massive UI that I'm designing. The way that my employer wants it, there are at least 100 labels. Now, I've always thought that in cases like this, breaking up the UI into smaller custom controls was the ideal way to go. However, someone recently told me that custom controls are really only for code re-use. What is the actual suggested practice for this?
EDIT
The finished form will look like this:
Now, I'm using WPF for the UI, and I'm thinking of breaking this down into smaller bits.
Based on your image i see some repetitions, each of this repetitions could be a custom UserControl
But it depends on the usability is it easier to write a custom UserControl so do it but if it would reduce the readability of your code and it also adds additional complexity don't do it
here are an example of what could be separate UserControl's
the green ones are possible useful encapsulations of logic
the orange ones maybe need some not market stuff (don't know enough about your software)
the red ones are the maybe's based on the intern use (from the visual part they are repetitions so the should custom UserControl)
Since your UI is read-only, I'd suggest using a grid.
Are you new to WPF? To break the View into bits WPF offers you CustomControls and UserControls. They are two very similar things yet completely different from each other. CustomControls are Buttons, Labels, TextBoxes, DataGrids...etc. They are basically simple stand-alone controls. UserControls are groups of stand-alone controls serving a purpose such as example a Button and a ComboBox next to each other so user can select something in ComboBox and confirm that by clicking the Button.
If you wish to display data from database I suggest you DataGrid which will give you a table-alike look with rows and columns and all that. If you wish to place few buttons next to DataGrid on which the user may click to insert a new row or to edit a certain cell then I suggest you to wrap all that with a UserControl which you can reuse in other places where you have to display and change data from database too.
You should be using a datagrid and can customize its template to render individual cells as Textblock (lighter version of Label) from a rendering perspective. The main difference between Textblock and Label is very minor things such as access keys and disabled state behavior. But from a WPF object hierarchy - Textblocks are much lighter. But besides that point - from your employer perspective - once you have customized the grid template and render them (so as they look as textblocks/labels) - your employer should have no problems.
Also as somebody suggested above - if you want to logically break sections of the UI since they maybe coming from a different table in db - then User controls is the way to go (for maintainability of code)
Let me know if you are looking for more technical details or need help further technically.
There is nothing wrong in making and using custom controls or user controls or defining some data templates which will be reused depending on how your data is organized.
For sure the UI looks pretty messy and some sort of grid should be used with templates for example where there is similar data. I also have the suggestion and first think about the data and the functionality before starting and let the UI be driven by that. For sure you will the reuse controls/templates. If you think in front on the model and behavior the UI can afterwards more easily changed.
Create your viewmodel correctly, implement the functionality in commands, use bindings, after that the UI will come naturally, reuse controls, use several grids, make the UI more user friendly using several regions, tabs, windows or anything that makes the user more comfortable.
I'm trying to build a maintenance form in WPF, using Telerik's WPF controls. The idea is to have a grid and a form that are bound to the same collection. Changes to the grid should be immediately reflected in the form, and vice versa. An online example using Telerik's Silverlight controls is here.
My specific problem is that when I enter a new record (by clicking on the "Add" icon in the upper-right of the DataForm), the record is added to both the grid and to the form's collection, but it seems to break the synchronization. The new row in the grid stays highlighted, like the grid thinks it's not done being edited, and while changes to the current record in the form are reflected in the grid, changes to the current record in the grid are no longer being reflected in the form.
But my real problem is more general than that. WPF controls, like Telerik's, are heavily dependent on binding, and in having what they bind to support specific behaviors. In this case, the underlying record needs to support INotifyIEditableObject, so that when the user hits the Cancel button on the form, the EditCancel method on the record can be called. Which is then responsible for setting its properties back to what they had been, and then raising a NotifyPropertyChanged event, so that controls that are informed that they have been so set.
When I didn't have EditCancel working right, I would hit cancel on the form and the values in the grid would not be changed. My guess as to what is going on with the inserts is that something in either my collection or by records doesn't support whatever it is that makes this work. The grid doesn't know that the form has finished editing the record because either my record or the collection hasn't told it.
And here's the real question: how can I find out what these third-party controls are expecting? Telerik's RadGrid can be bound to pretty much anything that can be IEnumerated. But all this neat enhanced functionality depends upon being bound to collections that are very much more specific. I don't get errors, when I bind to a collection that lacks facilities that are needed for certain functions to work, I just get a control that doesn't work.
How can I tell, when working with someone else's control, for which I do not have source code, what functionality it requires, in the objects it binds to?
Your best bet would be to browse Telerik's documentation or ask on their support forums
If that doesn't work, I like to use Snoop for debugging WPF's Visual Tree and Reflector for looking through compiled libraries
The winforms DataGridView has a virtual model and uses the OnCellValueNeeded method to gets cell values from a a user defined data store.
How do i do this in wpf? The DataGrid doesn't seems to have a OnCellValueNeeded method.
Thanks
Not sure if this already helps you:
DataGrid uses UI virtualization, what means that objects are not created before they are visible on screen and the corresponding properties of your source objects will not be called as long as they are not visible. It means also that ui-elements are recycled after they are no more visible.
This is for free and you don't have to do additional coding to use this feature. If I interprete your question right, the main question is, how to know that a property of a business-object is needed. For UI-virtualization, this is when the property is called the first time - You can do some lazy initialization. But beware to put too heavy initialization code into the properties (DB synchronous lookups etc), otherwise your DataGrid will become very slow and unhandy.
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).