I have this problem with my listview itemsource, you see I'm working in WPF, and the problem comes (I think) in VB, its like blocked, this new columns I added I cannot see in xaml, the columns are there but no info, and I can see the values if I put some breakpoints in the part I specify the itemsource list, and when I do this shows up:
That lock there most be the cause of my problem, but I do not know how to take it off my collection list. HELP PLEASE.
By the way I'm using properties to create a row and later bind that to xaml
You can't see that property in the list view because it is marked as Private. According to the documentation all binding source properties must be marked as Public.
Binding Sources Overview | Microsoft Docs:
Implementing a Class for the Binding Source
(...)
Other Characteristics
The properties you use as binding source properties for a binding must be public properties of your class. Explicitly defined interface properties cannot be accessed for binding purposes, nor can protected, private, internal, or virtual properties that have no base implementation.
The little padlock that you see on the icon doesn't mean that it's locked, it's just an indication that the property is marked as Private.
Related
I'm wondering what element can be used, when the only thing you want to change is the DataContext.
I'm aware that I could wrap it in a grid or something, but all of those are rather heavy weight when I just need to change the data context for a single element, so that I can more easily bind to attributes without them getting too long.
The concept of the WPF class hierarchy is described at Microsoft: WPF Architecture. There you can find the System.Windows.FrameworkElement:
The two most critical things that FrameworkElement introduces are data binding and styles.
Checking the properties of FrameworkElement, there the DataContext property is defined. This means the following capability is available:
Support for data binding and dynamic resource references: The property-level support for data binding and resources is implemented by the DependencyProperty class and embodied in the property system, but the ability to resolve a member value that is stored as an Expression (the programming construct that underlies both data binding and dynamic resources) is implemented by FrameworkElement. For more information, see Data Binding Overview and XAML Resources.
The Data​Context property is now available and used at all inherited controls, which you can see at the following class hierarchy:
My question is in the title. I read that a binding target must be a DP but a reply I got from a moderator on the WPF forum seemed to indicate that it was sufficient for my class to implement INotifyPropertyChanged in order to designate it as a binding target.
Targets of data bindings are required to be dependency properties. WPF data binding sources do not have to be dependency properties. Obviously there must exist some kind of mechanism for the source object to notify the outside world when the bound property has changed. For that you have to implement the INotifyPropertyChanged interface and has an event named PropertyChanged, which identifies the particular event that's changed with a string.
for more please have a look at this links
http://msdn.microsoft.com/en-us/library/ms522664.aspx
http://www.charlespetzold.com/blog/2006/03/210946.html
Databinding in WPF/Silverlight revolves around dependency properties, DataContext objects and DataSource objects. As far as I can tell, dependency properties are the same thing as ambient properties and their significance to binding is basically that if you put a bunch of widgets in a container then you only need to specify a DataContext for the container.
There are several parts to this question.
What is the difference between DataContext and DataSource, and how do they relate?
What manages cursors in WPF/Silverlight databinding? Is there a direct equivalence to the WinForms CurrencyManager and BindingContext?
How do I go about manipulating a Cursor in WPF/Silverlight databinding?
DataGrid seems to have a CurrentItem property. If you bind a bunch of widgets to the various columns of a datasource and they share the same datacontext as the datagrid then interactively moving the selected row in the datagrid changes the row whose values are expressed in the widgets. Could someone please explain to me how it all fits together? Preferably with reference to SL4.
When I do this:
private void buttonNew_Click(object sender, RoutedEventArgs e)
{
Guid newId = Guid.NewGuid();
Employee emp = new Employee() { Id = newId, FirstName = "NOT SET", LastName = "NOT SET" };
AtomDomainContext adc = employeeDomainDataSource.DomainContext as AtomDomainContext;
DomainDataSourceView ddsv = grid1.DataContext as DomainDataSourceView;
}
I get this compilation error:
The type 'System.ComponentModel.IPagedCollectionView' is defined in an assembly
that is not referenced. You must add a reference to assembly 'System.Windows.Data,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
D:\Argent\Views\ManageEmployees.xaml.cs, 57, 7, Argent
which sounds easy to fix but when I attempt to add a reference to the Argent project the list of references is empty; presumably one is confined to those assemblies that Silverlight deploys to the target computer. So now what do I do?
I found some answers so in the absence of a useful contribution from anyone else I'll answer my own question.
A DataContext is a kind of cursor object. You assign to the DataContext property any object or IEnumerable collection of objects to which you want to bind, and a wrapper is constructed around it. If you assign an IEnumerable, the DataContext surfaces a CurrentItem property that references one of the elements of the IEnumerable. If you assign something that isn't an IEnumerable, the DataContext wrapper behaves as though it contructs an IEnumerable and adds your object to the collection and then proceeeds as if that was what you passed in the first place, the object being set up as the CurrentItem.
One possible IEnumerable is the DomainDataSource, for which DataSource is a base clase.
Every widget in Silverlight has a DataContext property. Generally you don't set this directly, due to what Microsoft has taken to calling "dependency properties" which as far as I can tell are exactly the same as ambient properties, which is to say that unless you set them explicitly they "inherit" a value from the immediate container, which may in turn so inherit. So instead of setting the same IEnumerable as DataContext on a bunch of widgets, you make them all children of some container and set the DataContext for that, and they all miraculously get bound to the same cursor.
You can create a new DataContext object in XAML simply by explicitly specifying it; this creates a new instance and assigning it to the DataContext property of the widget on which you specify it; this is a new instance, a new cursor that is independent of any other DataContext.
In Silverlight4 you can reference the DataContext in use by another object; see element binding.
But a binding is only partly specified by a DataContext. Having specified a DataContext so that a widget has object foo contributing its context, specifying a binding path of A will look for a property named A on object foo and if this is found will mashall its value to and from your widget.
What's really confusing to the newbie is that while the whole binding can be specified in one spot, normally the context is specified miles away up a big complex container hierarchy, and just the path is specified on each widget, yet for (eg) binding the ItemsSource of a combobox to a lookup table you do specify the whole thing. I hope I've made it all a bit clearer for those following in my footsteps.
As for the location of the elusive 'System.Windows.Data', it's in %ProgramFiles%\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\System.Windows.Data.dll
I have a an object which is set to the DataContext in a Window. I have textboxes in the window which are bound to the properties on the object. There seems to be a delay however before the properties on the object are updated.
<TextBox x:Name="txtPropertyOne" Text="{Binding Path=PropertyOne,Mode=TwoWay,UpdateSourceTrigger=PropertyChanged}" />
If I change the values in a few textboxes then quickly try to access the properties to which they map, sometimes there are changes which aren't reflected in the properties of the object. I thought that was what the PropertyChanged UpdateSourceTrigger was supposed to take care of.
If I change the values in a few
textboxes then quickly try to access
the properties to which they map
I can interpret this statement in two ways:
You're trying to access the values on a background thread. In that case, you may be accessing the properties before the UI thread has had a chance to do its thing.
You're using a separate message on the UI thread to check the values. Bindings are updated at a priority lower than Send and Normal. So if your message is priority Send or Normal it will be processed before any pending binding updates.
If this doesn't answer your question, please clarify what you mean by "quickly trying to access the properties".
The basic rule of WPF Databinding is simple:
The target property must be a
dependency property, and you're
already correct, it's bound to Text
property of TextBox.
The source property can be a CLR
object (other than any derived WPF's
DependencyObject), but the object
must employ or implement its own
INotifyPropertyChanged.
Have you you already implemented INotifyPropertyChanged on your object?
A little background: I am loading a WPF UI from a database which is stored in a table of properties (Control type, label, margin, etc.) which I load into a class I call ControlPresenter. Basically I set ControlPresenter as the DataContext of a ContentPresenter and use a TemplateSelector to choose which type of control to load. The DataTemplate(s) load their properties off the DependencyProperties exposed by the ControlPresenter.
This all works extremely well. The problem I'm running into comes when I try to bind data (e.g. TextBox's Text property to a presenter's Name property) in other presenters (which have normal properties that implement INotifyPropertyChanged) to these controls. The control's DataContext is the associated ControlPresenter so I can't bind directly to the other presenters and I can't set up two bindings on the same dependency property (I can't bind the control and the desired presenter property to the same DP).
Possible solutions:
I could convert all of the other presenters to use DPs (extremely time consuming and prone to cause problems with inheritance)
I could use two DPs for each property I want to pass through and try to tie them together through changed notifications
Both of these seem problematic and prone to breaking so I'm hoping someone else has come up with a better solution.
Edit: I came up with a solution that works fairly well (see below). Thanks to everyone that looked at this and if you come up with a better method than I did please let me know.
There are several ways of accessing out of scope DataContexts.
1) ElementName Binding
This is probably the least useful as, in most real world scenarios, what you are trying to bind to is out of namescope anyway. But it is a way to access a parallel or parent Data Context as long as the Framework Element is within namescope.
<TextBox Text="{Binding ElementName=ControlSomewhereElseBoundToSomeOtherControlPresenter, Path=DataContext.SomeTextPropertyOnTheControlPresenter}" />
2) RelativeSource Binding
This is similar to #1 but using RelativeSource to navigate to the appropriate visual element and grab the DataContext. Of course, this assumes that the DataContext you are trying to get at is ABOVE where you currently are in the Visual Tree.
3) Use a Static Relay
You could expose your alternative ControlPresenters within a static class that acts as a facade to your ViewModel. Then, within each ViewModel construct instance properties that pass through to the static methods / properties. This is a common way for achieving shared storage across multiple View Models. I realize this technique would require you to alter your pattern a bit, but adding a simple ViewModel wrapper around these "ControlPresenter" classes seems a lot more simple than the options you described.
I ended up setting the bindings in code by setting Binding.Source to the desired ViewModel and then using the path in the database for Binding.Path. I store the bindings in a Dictionary(Of DependencyProperty, BindingBase) and when the Control loads I use BindingOperations.SetBinding to set the bindings on the control. This seems to work pretty well except for occasional order of operations issues (e.g. If you set SelectedItem/SelectedValue prior to the ItemsSource it will be set but won't display in a ComboBox).