Wpf – How to set Mouse Cursor in XAML / WPF

wpfwpf-controlsxaml

How can I set the Mouse cursor in xaml?

What's the use of Cursor property in every control? Please don't answer as Cursor="Arrow" cause this is not working.

Only way I can do it right now is from code behind by
Mouse.OverrideCursor. Can I do it simply using XMAL?

I have a Hierarchy of controls where there is a GridSplitter in between somewhere. I'm trying to set the Cursor to SizeNS but it's set to default as default Arrow. What Should I do?

Best Answer

In WPF Cursor creates problem when controls are declared in hierarchy and properties get overwritten.

If you strictly want to set Cursor in a control use ForceCursor property of FrameworkElement class.

Syntax:

    <StackPanel Name="CursorForced" ForceCursor="true" Cursor="Hand">
        <Label>Cursors Forced</Label>
        <TextBox>Fill me in!</TextBox>
    </StackPanel>

In above example if I don't use ForceCursor the Cursor will be different over TextBox not as I defined in parent control.

MSDN link to How to Force Cursor

Related Solutions

.net – How to use WPF bindings with RelativeSource

If you want to bind to another property on the object:

{Binding Path=PathToProperty, RelativeSource={RelativeSource Self}}

If you want to get a property on an ancestor:

{Binding Path=PathToProperty,
    RelativeSource={RelativeSource AncestorType={x:Type typeOfAncestor}}}

If you want to get a property on the templated parent (so you can do 2 way bindings in a ControlTemplate)

{Binding Path=PathToProperty, RelativeSource={RelativeSource TemplatedParent}}

or, shorter (this only works for OneWay bindings):

{TemplateBinding Path=PathToProperty}

.net – In WPF, what are the differences between the x:Name and Name attributes

There really is only one name in XAML, the x:Name. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name by using the RuntimeNamePropertyAttribute on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.

The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement introduces a Name property.

In general, a class does not need to store the name for x:Name to be useable. All x:Name means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.

So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.

In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.

Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.

See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.

Best Answer

Related Solutions

.net – How to use WPF bindings with RelativeSource

.net – In WPF, what are the differences between the x:Name and Name attributes

Related Topic