This question already has an answer here:
When to use Path in WPF Binding?
(1 answer)
Closed 9 years ago.
I am very new to WPF and the binding. I see the following through the application and I was wondering what the difference is.
{Binding aField}
{Binding Path=aField}
When should I use one over the other?
There is no difference; In the first example you are creating the binding using the constructor Binding(string), in the second one you are assigning a property using the initializer, calling the Binding() constructor
There is no difference. Path is a default property and does not need to be specified in binding markup extension MSDN:
The Binding markup extension uses Binding.Path as a conceptual "default property", where Path= does not need to appear in the expression. If you specify a Binding expression with an implicit path, the implicit path must appear first in the expression, prior to any other bindProp=value pairs where the Binding property is specified by name. For example: {Binding PathString}, where PathString is a string that is evaluated to be the value of Binding.Path in the Binding created by the markup extension usage. You can append an implicit path with other named properties after the comma separator, for example, {Binding LastName, Mode=TwoWay}.
Related
This question already has answers here:
An attribute argument must be a constant expression, ...- Create an attribute of type array
(3 answers)
Closed 3 years ago.
I am trying to set the TableAttribute for my view like so:
[Table(LSODatabase.databaseString)]
However the following error is thrown:
An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type.
A workaround I am trying to avoid is making another view and manually setting the strings, however I have a lot of views and would like to avoid this as much as possible.
The error is somewhat self explaining. The arguments you put into your attribute constructors have to be a constant expression, typeof expression or array creation expression. The databaseString field of your LSODatabase isn't constant unless you add the const modifier. Constant means that you can say at compile time what the value of the property will be and that it won't be able to change at runtime.
As the error says, you must use either a constant, a typeof expression or an array creation.
One possible solution would be:
public class LSODatabase
{
public const string databaseString = "myDatabase";
}
Now you can use that as an argument for your attribute.
All, the question is a simple one. The following binding does not work, that is, the ascociated Trigger does not fire
<DataTrigger Binding="{Binding dataAccess:DataGridTextSearch.IsAnyTextMatch,
ElementName=dataGrid}" Value="false">
to fix this and make the binding work, we place the binding reference in braces, as follows
<DataTrigger Binding="{Binding (dataAccess:DataGridTextSearch.IsAnyTextMatch),
ElementName=dataGrid}" Value="false">
Why does adding the braces resolve the reference/binding problem and what is going on?
Thanks for your time.
This is because The Binding cannot determine the complete Expression you want to bind to. If you put it into braces the complete expression (with namespace etc.) can be determined correctly.
If you write (dataAccess:DataGridTextSearch.IsAnyTextMatch) with braces the markup parser will take your whole binding as ONE expression. Otherwise it would stuck trying to bind to dataAccess:. With braces you will have an explicit statement that this is one single expression
I hope you finall got me :)
Multiple Property (Indirect Property Targeting)
<Binding Path="propertyName.propertyName2" .../>
propertyName must resolve to be the name of a property that is the current DataContext. The path properties propertyName and propertyName2 can be any properties that exist in a relationship, where propertyName2 is a property that exists on the type that is the value of propertyName.
Single Property, Attached or Otherwise Type-Qualified
<object property="(ownerType.propertyName)" .../>
The parentheses indicate that this property in a PropertyPath should be constructed using a partial qualification. It can use an XML namespace to find the type with an appropriate mapping. The ownerType searches types that a XAML processor has access to, through the XmlnsDefinitionAttribute declarations in each assembly. Most applications have the default XML namespace mapped to the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace, so a prefix is usually only necessary for custom types or types otherwise outside that namespace. propertyName must resolve to be the name of a property existing on the ownerType. This syntax is generally used for one of the following cases:
The path is specified in XAML that is in a style or template that does not have a specified Target Type. A qualified usage is generally not valid for cases other than this, because in non-style, non-template cases, the property exists on an instance, not a type.
The property is an attached property.
You are binding to a static property.
For use as storyboard target, the property specified as propertyName must be a DependencyProperty.
This question already has answers here:
Why does WPF support binding to properties of an object, but not fields?
(2 answers)
Closed 5 years ago.
I was googling for this point where why the local or global variables are not allowed as sources for WPF data binding; only the wrapping property can be bound to.
So the question is where properties are the wrapper over the variables then why these properties are allowed and the variables are not allowed.
I need to know under the hood system.
The mechanisms used for binding (PropertyDescriptor, DependencyProperties etc.) only use properties, that's the reason you can't bind to fields. Properties can provide validation, change notification and more, which is another reason to prefer properties. Fields provide none of these.
Also, using public fields is usually bad practice, so why should they bother implementing binding to fields? It would only promote those bad practices.
Well, it's not completely true. You can use a field for a binding, but first you have to declare it like a resource and after access it via resource key in binding declaration.
When you're going to bind to code binding to a property is done for be able to iject also OnPorpertyChanged notification too.
I have a binding of the form:
Path=SpecialCollection[0]
The SpecialCollection class extends ObservableCollection and has an indexer property.
public T this[string propertyValue]
{
get
{
// do stuff
return default(T);
}
}
My problem is that the binding attempts to get the indexer property value, instead of returning the 0th item in the collection. Is there a way to force the binding to treat 0 as an integer so it returns a collection element, instead of invoking the collection's indexer property's getter?
According to MSDN you can tell the binding the type of the value entered as index:
Inside indexers you can have multiple indexer parameters separated by commas (,). The type of each parameter can be specified with parentheses. For example, you can have Path="[(sys:Int32)42,(sys:Int32)24]", where sys is mapped to the System namespace.
I noticed that the Binding constructor taking a path string uses another PropertyPath constructor than the default PropertyPath type converter, said PropertyPath constructor does not work in this scenario. To avoid the problem avoid the Binding constructor by setting the Path property manually which invokes the conversion via type converter.
<!-- Does not work -->
<TextBlock Text="{Binding [(sys:Int32)0]}"/>
<!-- Does work -->
<TextBlock Text="{Binding Path=[(sys:Int32)0]}"/>
Actually you have two indexer properties, one that takes an int argument and one that takes a string argument. Frankly, I don't know how the binding expression chooses which indexer to use when it is ambiguous. If there is only one then it can coerce the index to the type of the indexer argument. If there are two, it can either throw an exception or choose one according to a heuristic. In this case, it apparently chose the wrong one.
To solve this problem you can either move your string indexer "down a level" so it hangs off of a new property so that it doesn't compete with the list indexer or if all you need is List[0] you can add a First property and bypass either indexer.
This question already has answers here:
Closed 11 years ago.
Possiblity:
What is a dependency property?
What is a dependency property? How does it differ from a normal property? What is the purpose of dependency properties? And why it is used, when it is used?
Dependency property: A property that is backed by a DependencyProperty.
The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs.
These other inputs might include system properties such as themes and user preference, just-in-time property determination mechanisms such as data binding and animations/storyboards, multiple-use templates such as resources and styles, or values known through parent-child relationships with other elements in the element tree.
It has Following capabilities:
The property can be set in a style.
The property can be set through data binding.
The property can be set with a dynamic resource reference.
The property can inherit its value automatically from a parent element in the element tree.
The property can be animated.
The property can report when the previous value of the property has been changed and the property value can be coerced.
The property reports information to WPF, such as whether changing a property value should require the layout system to recompose the visuals for an element.
The property receives support in the WPF Designer for Visual Studio. For example, the property can be edited in the Properties window.
(Content taken from MSDN)
Dependency properties store their values outside the class, so properties can be assigned to an object without having to change the object's class. They also support a situation common in WPF where an object may have very many properties, but only a few have non-default values. Dependency properties can have default values, so this reduces memory usage. There is lots more, read the article: Dependency Properties Overview on MSDN.
I think the MSDN article can give you more information.
From what I read is that a Dependency Property relies on other values.
The purpose of dependency properties
is to provide a way to compute the
value of a property based on the value
of other inputs. These other inputs
might include system properties such
as themes and user preference,
just-in-time property determination
mechanisms such as data binding and
animations/storyboards, multiple-use
templates such as resources and
styles, or values known through
parent-child relationships with other
elements in the element tree. In
addition, a dependency property can be
implemented to provide self-contained
validation, default values, callbacks
that monitor changes to other
properties, and a system that can
coerce property values based on
potentially runtime information.
Derived classes can also change some
specific characteristics of an
existing property by overriding
dependency property metadata, rather
than overriding the actual
implementation of existing properties
or creating new properties.
If you are talking about a property with a Dependency attribute (as defined in Microsoft.Practices.Unity)
[Dependency]
public string MyProperty { get; set; }
Then this is used for dependency injection (DI) by the Unity framework. Basically, the property value is set at runtime by the DI framework, rather than being set directly in your code.
However, there is another Dependency attribute defined in System.Runtime.CompilerServices. Please could you update your question with which one you mean.