I need some help/guidance on WinForms data binding and I can't seem to get Google to help me with this one.
Here is my scenario. Consider the following classes which is similar to what I need:
public class Car
{
public string Name { get; set; }
public List<Tire> Tires { get; set; }
}
public class Tire
{
public double Pressure { get; set; }
}
My instances of this will be an object of class Car with a List with four Tire objects. Note that I will always have a known number of objects in the list here.
Now I want to data bind this to a Form containing five textboxes. One textbox with the name of the car and one textbox with each of the tires pressures.
Any idea on how to make this work? The designer in VS does not seem to allow me to set this up by assigning to list indexes like Tires[0].Pressure.
My current solution is to bind to a "BindableCar" which would be like:
public class BindableCar
{
private Car _car;
public BindableCar(Car car)
{
_car = car;
}
public string Name
{
get { return _car.Name; }
set { _car.Name = value; }
}
public double Tire1Pressure
{
get { return _car.Tires[0].Pressure; }
set { _car.Tires[0].Pressure = value; }
}
public double Tire2Pressure
{
get { return _car.Tires[1].Pressure; }
set { _car.Tires[1].Pressure = value; }
}
public double Tire3Pressure
{
get { return _car.Tires[2].Pressure; }
set { _car.Tires[2].Pressure = value; }
}
public double Tire4Pressure
{
get { return _car.Tires[3].Pressure; }
set { _car.Tires[3].Pressure = value; }
}
}
but this becomes really ugly when my lists contains 20 instead of 4 objects, and for each of those objects I want to bind against 6 properties. That makes a huge "BindableObject"!
You should note that you can bind controls to any object type that implements the interfaces IList, ICollection or IEnumerable or inherits from classes that implement these interfaces. Generic collections also qualify for this kind of binding.
These are internally converted to an IBindingList instance.
Check out the following links for more information:
Roadmap for Windowsforms databinding - Takes a very comprehensive look at the implementation and possibilities and provides a variety of links to other KB articles.
Winforms Object binding - Rockford Lhotka's article on the subject. Provides a Windows forms designer-oriented way of implementing databinding.
Databinding with Windows forms 2.0 - This book by Brian Noyes explores various aspects of Databinding, both in complex and simple scenarios.
While the WinForms designer may not let you do this, have you tried setting up the binding in code? I imagine there is no problem binding a textbox to someCar.Tires[1].Pressure.
Related
In a MVP applicaiton if I want to encapsulate a ListBox in a public property so that I could expose the property through an interface to the presenter. I should be able to update the items in the ListBox though this public property. I've tried in several ways to do this
public BindingSource Permission
{
get { return lstGivenPermissions.DataSource; } // Casting error
set { lstGivenPermissions.DataSource = value; }
}
I tried several types for the property like IEnumereble<>, List<> etc. but always either setter or geter shows a casting error.
One option is to have separate properties for get and set.
public ListBox gettingPermission
{
get {return lstGivenPermissions; }
}
public BindingSource Permission
{
set { lstGivenPermissions.DataSource = value; }
}
Is it possible to use a single property in this case or else having two properties is a acceptable solution?
EDIT : I'm using MVP pattern and my requirement is that my presenters are talking to the Views through interfaces. So that if I want one of my presenters to access controllers (like text boxes) in the View, those controllers should be encapsulated in properties. So that I can expose through the interface.
This solved my problem.
public List<string> GivenPermission
{
get { return lstGivenPermissions.Items.Cast<string>().ToList(); }
set { lstGivenPermissions.DataSource = value; }
}
I have a ListBox, and it's items consist of custom class objects (can be any class).
Then I set the DisplayMemberPath so the ListBox shows the right property of that custom class fine.
Now I need to enumerate the Items list of ListBox, and get the DisplayMember value of each item in the list, without knowing the type of the class in the list. Is there any way to get this DisplayMember value without Reflection?
In WPF, you don't need to implement an interface, or a base class for a container control to read the value of a property. In an ideal world, it would make sense to declare a base class or interface and have all of your custom classes extend, or implement these, but the benefit of that is really to keep your data type safe.
For example, in WPF, this is perfectly legal and will work just the same:
public class RadioButtonData
{
public string Label { get; set; }
public bool IsSelected { get; set; }
}
public class CustomData
{
public string Label { get; set; }
public string Value { get; set; }
}
...
private ObservableCollection<object> objects = new ObservableCollection<object>();
public ObservableCollection<object> Objects
{
get { return objects; }
set { objects = value; NotifyPropertyChanged("Objects"); }
}
...
Objects.Add(new RadioButtonData() { Label = "Some Value" });
Objects.Add(new CustomData() { Label = "Another Value" });
...
<ListBox ItemsSource="{Binding Objects}" DisplayMemberPath="Label" />
So as long as your various classes have the same name of property, then they will all be displayed in the same way, like above. They don't even have to be of the same type... just as long as the name matches that used in the ListBox.DisplayMemberPath property.
UPDATE >>>
Ah sorry, I misunderstood your question. In the case that you want to access these property values in code, then you have four basic options:
Define an Interface with a particular property and make your custom classes implement it.
Declare a base class with a particular property and make your custom classes extend it.
Create a (potentially long) section of if else statements that checks the type of each object and then accesses the relevant property.
Use reflection.
In my personal opinion, I would recommend options 1 or 2 first, then 4 and lastly 3. I'm really not sure what you have against reflection, but it's really not that bad, or slow... I'd certainly prefer to use it rather than having an else if statement for every possible type used.
When .NET 4.5 was released i started using such great Attribute as CallerMemberName. It's easier to understand code, developers can write it faster also. It's like a snippet, not only a feature for debug/test purposes.
So I have a question. Is it normal to create and use something like this?
public class PropertyStore
{
Dictionary<string, object> data = new Dictionary<string,object>();
ViewModelBase modelBase;
internal PropertyStore(ViewModelBase _base)
{
modelBase = _base;
}
public void SetValue<T>(T value = default(T), [CallerMemberName] string prop = "")
{
T prev = GetValue<T>(prop);
if ((prev == null && value == null) || (prev != null && prev.Equals(value))) return;
data[prop] = value;
modelBase.OnPropertyChanged(prop);
}
public T GetValue<T>([CallerMemberName] string prop = "")
{
if (!data.ContainsKey(prop))
data[prop] = default(T);
return (T)data[prop];
}
}
Class-helper, that makes other class more readable, and also we have list of our properties without need to use Reflection.
The usage is:
public class SampleClass : ViewModelBase
{
PropertyStore PropertyStore;
public SampleClass ()
{
PropertyStore = new PropertyStore(this);
}
public string Key
{
get { return PropertyStore.GetValue<string>(); }
set { PropertyStore.SetValue(value); }
}
public DateTime Date
{
get { return PropertyStore.GetValue<DateTime>(); }
set { PropertyStore.SetValue(value); }
}
public bool IsSelected
{
get { return PropertyStore.GetValue<bool>(); }
set { PropertyStore.SetValue(value); }
}
}
The class ViewModelBase here simply implements INotifyPropertyChanged interface.
As I understand, this approach is something like Microsoft Dependency Properties, but I don't need all power of DependencyObject class, and I don't want inherit it.
With something like this I can use Binding, because it's enough to implement INotifyPropertyChanged, also we have no fields (as for me, i try to use properties smarter, than using fields directly (however, there is no problem to use Dictionary directly ^_^))
Sorry for my bad English... Not main language and not much practice.
Another Sample (after moving Methods to base class)
public class SampleClass : ViewModelBase
{
public string Key
{
get { return GetValue<string>(); }
set { SetValue(value); }
}
public DateTime Date
{
get { return GetValue<DateTime>(); }
set { SetValue(value); }
}
public bool IsSelected
{
get { return GetValue<bool>(); }
set { SetValue(value); }
}
}
No diff with Microsoft's WPF Property System.
Only feature you'll get with it is an ability to access property values via Dictionary.Get|Set methods.
You can get this ability with field based implementation of INotifyPropertyChanged. You can access property values by its name using dictionary, with property name to precompiled delegate mapping like it done in Yappi project.
var dateValue= Property<SampleClass>.Get<DateTime>(this,"Date");
Property<SampleClass>.Set<DateTime>(this,"Date",DateTime.Now);
Both can be rewritten as extension methods.
Nice idea, property bag without reflection and it will even work with obfuscation.
I don't see major problems with it but you may consider the following:
The prop parameter is optional so potentially a bug can be introduced by given a value in the call.
Value types will get boxed.
Access to the fields is relatively more expensive, can be a factor more expensive as you have much more code in a simple get (especially with boxing).
Dictionary takes more space than the number of properties you keep in (especially with boxing).
Each property also stores a string of the property name adding to the overhead.
I have a Document object that looks like this:
public class Document
{
public Title { get; set; }
public Extension { get; set; }
public byte[] Data { get; set; }
}
The Extension is "pdf", "doc", "docx" and the like. This document is used for storing documents in a database (it's actually a DevExpress XPO object).
The problem I'm having is, I am binding a list of these objects to an imagelistbox, which has an associated image list of the icons to display for each file type. How can I set the image index on the imagelistbox item based on the Extension without storing the index in the domain object?
In WPF, I would have used the MVVM pattern to solve that issue : the XPO object wouldn't be directly used by the UI, instead a ViewModel object would expose the necessary properties so that they can easily be used in binding scenarios. MVVM is specific to WPF, but I believe the MVP pattern is very similar and can easily be used in Windows Forms. So, you could create a Presenter object which would act as an adapter between the UI and the XPO object :
public class DocumentPresenter
{
private Document _document;
public DocumentPresenter(Document document)
{
_document = document;
}
public string Title
{
get { return _document.Title; };
set { _document.Title = value; };
}
public string Extension
{
get { return _document.Extension; };
set { _document.Extension = value; };
}
public byte[] Data
{
get { return _document.Data; };
set { _document.Data = value; };
}
public int ImageIndex
{
get
{
// some logic to return the image index...
}
}
}
Now you just have to set the DataSource to a collection of DocumentPresenter objects, and set the ImageIndexMember to "ImageIndex"
Disclaimer : I never actually used the MVP pattern, only MVVM, so I might have got it wrong... anyway, you get the picture I guess ;)
Is there a way to bind the child properties of an object to datagridview? Here's my code:
public class Person
{
private string id;
private string name;
private Address homeAddr;
public string ID
{
get { return id; }
set { id = value; }
}
public string Name
{
get { return name; }
set { name = value; }
}
public Address HomeAddr
{
get { return homeAddr; }
set { homeAddr = value; }
}
}
public class Address
{
private string cityname;
private string postcode;
public string CityName
{
get { return cityname; }
set { cityname = value; }
}
public string PostCode
{
get { return postcode; }
set { postcode = value; }
}
}
And I want to show ID, Name, CityName when an object of the type Person is binded to datagridview. Note that CityName is a property of HomeAddr.
IF you have the DataGridView to AutoGenerateColumns = true, there's really no simple way to do this. Your best bet is to set up the DataGridView ahead of time, and manually populate the DataGridView.
Alternatively, you can implement the ITypedList but that's a bit of a pain if you ask me.
Hmm, I've found a way to do this, in FarPoint.
But you can do this in DataGridView, if your object doesn't have a list type property.
You can also look here
http://www.mail-archive.com/advanced-dotnet#discuss.develop.com/msg06383.html
BLToolkit has BLToolkit.ComponentModel.ObjectBinder
Those features are:
Support for field binding along with property binding.
Support for inner class field and property binding such as Order.Address.Line1.
Support for the ObjectView feature which is available by assigning an object view type to the ObjectBinder.ObjectViewType property. An object view is an object that implements the IObjectView interface. This interface includes only one property - object Object { get; set; }. An object view can implement additional properties based on the assosiated object. The ObjectBinder will combine all of these properties with main object properties and create a single PropertyDescriptor collection. This feature can be used to separate UI presentation logic from business model objects and to keep them clean. ObjectView should be a stateless, lightweight object as its single instance can be assigned to many assosiated objects.
The ObjectBinder is optimized for high performance applications such real-time multithreaded message processing and distribution banking systems. So it does not use reflection to access objects. The standard way (which is used by the BindingSource) is to call the TypeDescriptor.GetProperties method to get a PropertyDescriptor collection. This method creates property descriptors that access object properties by reflection. The ObjectBinder has its own mechanism to avoid unnessasy reflection and boxing/unboxing operations.