I'm new with DOT.NET...
I'm trying to do:
Build a winform with tree of lectures
below i put a propertyGrid
The propertyGrid must display the details of Lecture:The Subject,language ang Lectors.
I want to add lectors to certain lecture "Lectors Collection" property in collection editor
Question:
I need the LectureID parameter to be passed in the constructor of new Lector, for connecting the newly added lector record (in lectors collection of current Lecture) to his lecture.
How can i do this?
You'll have to write a TypeConverter so you can override its CreateInstance() method. PropertyGrid is a quick solution for simple classes but gets awkward in a hurry. Consider that it might not be the best UI solution. DataGridView is well suited to editing collections.
Related
I'm trying to create a wpf control consisting of a list with an element at the end to add a new item (kind of what some grids have). I've been googling around trying to find a similar component but I've found nothing.
I'm new to wpf and willing to write it from scratch if there is nothing similar.
Any ideas will be appreciated.
Thanks!
A DataGrid can do that (does so by default), if your item has no default constructor you can use a BindingList<T> and factory code via the AddingNew event, of course your collection needs to implement IList so items can be added in any case.
For other controls you can also bind them to collection views that support adding, in that case you need to style the NewItemPlaceholder (make it a Button with adding logic for example).
How to declare a BindingSource in VB using WPF? I can't use a command like BindingSource.CancelEdit() like I used to when using Windows Form instead of WPF...
You could use a BindingGroup for that: set a BindingGroup on an element in XAML which contains all the controls that edit your object. By default, this will set the UpdateSourceTrigger on these controls to Explicit, which means that you will have to call BindingGroup.UpdateSources in order to actually change the properties of the object which is currently edited. So, you would do that in a Submit command or something similar.
If you want to cancel the edit, you can do that using BindingGroup.CancelEdit. This will throw away the cached values in the controls and reset them to the values of the bound properties.
I think this is a lot easier than implementing IEditableObject or a Memento...
The short answer is not good news - the isn't an equivalent method. Instead your approach needs to be a little different. One approach would be to implement the IEditableObject on your underlying class (or wrap it in an editable class). The second would be to implement Undo/Redo functionality. I think you will find searching for the terms bolded above and/or the memento pattern you will find lots of good examples, below is one.
Cancelling an update with WPF Binding
Do you know how event from "Add_Form" can be listened from "MainForm"? I code in WPF 2010(Visual Studio).
My program has two forms - "MainForm" and "Add_Form". "MainForm" has "Student_DataGrid" which has a register of students and button("btn_add_student") which invokes "Add_Form"(Form which has textblocks for input data of students). After clicking "btn_add_student" shows "Add_Form", further, I fill in data in textblocks and push the button "btn_add_student". New student is added in Data Base and "Add_form" is closed. Then "Student_DataGrid" on "MainForm" must be reloaded.
In other words I want to listen event on Add_Form from MainForm. I can do it in C#, but I can't do it in WPF. I'll be glad to any help.
Seems you haven't explored the strength of WPF i.e. Binding. These tutorials will get you going Binding Tutorial and one from msdn.
All you need to do in your case is bind your grid to an ObservableCollection and while adding a new student, add the object in this collection. Grid will automatically get refreshed.
If "Add_Form" and "MainForm" are binding to the same source, "Student_DataGrid" on "MainForm" needn't reloaded.
WPF can do it for u.
I found the way to solve it:).
I just made whole class of events:).
Here you are!
I'm developing a fairly simple WPF application to display an object hierarchy plus detail of the selected object, with a UserControl wrapping a TreeView in the left pane (the tree control), and another UserControl wrapping a ListView/GridView on the right (the details control).
The tree control uses MVVM following this Josh Smith article reasonably closely, and has a number of ViewModel types all derived from the same base type, TreeViewModel. The main window is set up using a MainWindowViewModel as in this Josh Smith article and exposes the TreeViewModel used to populate the first generation of the tree control.
However, when I want to populate the details pane on the right, I have the problem that the SelectedItem of the tree control is derived from TreeViewModel when I need a completely different type of ViewModel for the details pane which will expand the object into a table of properties/values using reflection.
So, questions:
Is it appropriate for the MainWindowViewModel to expose the TreeViewModel for the tree control? I believe that the answer here is yes, but am open to suggestions to the contrary.
How should the selected item in the tree control be adapted to the right ViewModel type for the details pane? One option seems to be that the MainWindowViewModel tracks the selected item in the tree and does the adaption, exposing it as another property, but I'm not sure if there is a better solution.
I'm new to WPF and the MVVM pattern, so please excuse the fairly basic nature of the question. I've done a fair bit of reading around the background of the pattern, looked at some sample apps etc. but I can't quite find anything specific enough to make me confident of the answer. I also realise that MVVM may be overkill for an app this simple, but I'm using it partly as a learning exercise.
1.Is it appropriate for the MainWindowViewModel to expose the
TreeViewModel for the tree control?
I belive yes. The model should hide the look from teh logic FOR THE LOOK, but it can not hide thigns like logical structure.
2.How should the selected item in the tree control be adapted to the right
ViewModel type for the details pane?
One option seems to be that the
MainWindowViewModel tracks the
selected item in the tree and does the
adaption, exposing it as another
property, but I'm not sure if there is
a better solution.
IMHO not.
Working on the similar problem I came to the conclusion that
object Tag { get; set; }
property is inevitable :( except maybe for some rare situations (only 1 type of objects in the entire treeview).
However, when I want to populate the details pane on the right, I have the problem that the SelectedItem of the tree control is derived from TreeViewModel when I need a completely different type of ViewModel for the details pane which will expand the object into a table of properties/values using reflection.
If you're really, really concerned about this, you can build a higher-order view model class that exposes two different properties - one of type TreeViewModel and one of type DetailsViewModel. Then the main window's view model will expose the same object to both the tree control and the details control, but the logical structure of the two view types will be decoupled from one another.
Logically, the selected item in the tree control and the item that's appearing in the details control are the same thing. While the details control doesn't present information about the thing's parent/child relationships, and the tree control doesn't present information about the thing's name/value pairs, it's still the same thing. There's probably not really any need to be too concerned over the fact that a single object representing a thing exposes a property that only one view of that thing uses.
I have a List<Foo> from a non-WPF assembly which I'm attempting to databind to a WPF <ListBox>. Initially, the list items display correctly, but when I add a new item to the List<Foo>, the listbox doesn't add a list item. How do I tell the list box to re-bind / update / refresh the data and show the new item?
Although using an ObservableCollection is the best way, to answer the actual question, the way to update manually is to call BindingExpression.UpdateTarget
You should use a ObservableCollection instead, then you'll get updates automatically.
Thanks for posting this answer. Even if you use ObservableCollection, you may need to use BindingExpression.UpdateTarget. This can be the case if the collection is not in the UI thread. I've been writing some multi-threaded WPF apps, and I've been finding myself having to strip out data binding when I move model code to another thread, because I can't count on the update system to really work. While I find data binding to be a great concept, I think the opaqueness of the data binding system has been a real hindrance for my adoption of it. (Sorry for the rant!) Thanks again, Adam.