3

If I have this:

    public class BoardCalc : FrameworkElement
    {
        public BoardCalc()
        {
            this.Loaded += BoardCalc_Loaded;
        }

        void BoardCalc_Loaded(object sender, RoutedEventArgs e)
        {
            Boards = Math.Floor(LengthRequired / 16);
            BoardsRequired2 = Math.Floor(LengthRequired / 16);
        }

        public Double LengthRequired { get; set; }

        private Double _Boards;
        public Double Boards
        {
            get
            {
                return _Boards;
            }
            set
            {
                _Boards = value;
            }
        }


        //public Double Boards
        //{
        //    get { return (Double)GetValue(BoardsProperty); }
        //    set { SetValue(BoardsProperty, value); }
        //}

        //// Using a DependencyProperty as the backing store for Boards.  This enables animation, styling, binding, etc...
        //public static readonly DependencyProperty BoardsProperty =
        //    DependencyProperty.Register("Boards", typeof(Double), typeof(BoardCalc), null);

        public Double BoardsRequired2
        {
            get { return (Double)GetValue(BoardsRequired2Property); }
            set { SetValue(BoardsRequired2Property, value); }
        }

        // Using a DependencyProperty as the backing store for BoardsRequired2.  This enables animation, styling, binding, etc...
        public static readonly DependencyProperty BoardsRequired2Property =
            DependencyProperty.Register("BoardsRequired2", typeof(Double), typeof(BoardCalc), null);



    }

And I do this:

 <StackPanel xmlns:Boards="clr-namespace:BoardsUtil" >
             <Boards:BoardCalc x:Name="boardCalc1"
                LengthRequired="5280"  />

             <TextBlock Text="{Binding ElementName=boardCalc1, Path=Boards}" />

             <TextBlock Text="{Binding ElementName=boardCalc1, Path=BoardsRequired2}" />

         </StackPanel>

Two Part question:

  1. When I use a dependency property, the Boards value will be calculated at in the designer and show 330 boards. If I use a regular property it will be 0 at design time. At runtime, either one works. Is this something we expect? If so, or if not, can someone explain to me WHY this is, so I can work around it and check to see if the rest of my code is actually working.

  2. Should I be using a dependency property for LengthRequired? If you set a property from XAML, you should use dependency yes? But if you merely BIND to a property from XAML you can use a regular property? Is this the behavior we see here? Is this what we expect? No? Yes? WHY, so I can decide what to do.

Andyz Smith
  • 698
  • 5
  • 20

2 Answers2

4

The main reason to use dependency properties is to allow the underlying subsystem to provide additional UI/XAML/WPF based functionality, namely:

1) Binding. In this code:

<Slider x:Name="slid1" Maximum="5280" Minimum="16" Value="250" />
<Boards:BoardCalc x:Name="boardCalc1"
            LengthRequired="{Binding ElementName=slid1,Path=Value"  />

LengthRequired must be a dependency property. You can set LengthRequired like this

LengthRequired = "5280"

and you can do this

Text={Binding ElementName=boardCalc1, Path=LengthRequired} ...

but you can't SET LengthRequired using the Binding extension.

2) Animation 3) Styling

Same basic principle. To allow the underlying UI subsystem to animate from 0 to 100 or whatever, or to get the subsystem to pick up Styling and Themes and whatever, it must be a dependency property.

1,2,3. Reasons to use dependency property. For regular properties you can jam in an INotify.

Andyz Smith
  • 698
  • 5
  • 20
2

Boards value will be calculated at in the designer

To quote MSDN (Dependency Property Overview)

The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs.

Design mode is not runtime mode and the designer works with dependency properties because it specifically reflecting for them. The designer is not subscribing to INotifyPropertyChanged, nor does it interact with normal properties as it does dependency properties.

Should I be using a dependency property for LengthRequired?

I would put a notify property change on it, but unless you are creating a custom control, using a Dependency property is overkill.

If you set a property from XAML, you should use dependency yes

No, one can bind (set) to any property in XAML for it is just reflection. Binding is reflecting off of an item in the data context via a route (pathing info) provided.

But the act of binding is different than the act of getting data which occurs after binding.

But if you merely BIND to a property from XAML you can use a regular property?

Yes, but in most cases use the INotifyPropertyChanged operation to help with binding and retrieving data.


Use these basic rules

  • Use dependency properties on controls because they are identifiable during design mode for the consumer of the control. Otherwise the user needs to find the property and cannot set the value in XAML; unlike a dependency property.
  • Any property can be bound to, but changes that occur may not be telegraphed to anything which it is bound to...to provide that process good data, use INotifyPropertyChanged operations.
ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
  • In fact, adding the implementation of INotifyPropertyChanged does affect the designer. It has the same value as the DependencyProperty now. – Andyz Smith Jun 10 '15 at 22:52
  • Can you describe further how they [dependency properties] are 'identifiable during design mode'. Or how the user needs to 'find' the property. or 'Cannot set the property'. ?? – Andyz Smith Jun 10 '15 at 22:54
  • @AndyzSmith What is your ultimate goal? A working version during design time? The designer does what it does and can show data on the screen up to a point. If one is creating a control use dependency properties, if one is not use normal properties. – ΩmegaMan Jun 11 '15 at 12:06
  • Why use dependency properties at all? You can set regular properties from XAML. You can bind to regular properties from XAML. You can keep the designer working with regular properties with a quick INotify. – Andyz Smith Jun 11 '15 at 12:33
  • 2
    @AndyzSmith the main reason for dependency properties, since they are static, allow for a non initiated control to express attributes. When one is designing and drops a control on the design surface, one can change things like `Width`, `Height`, `Text` because those are exposed as dependency properties. The control has non dependency properties, but those are not to be shown to the user. Otherwise without DPs one could only hook up controls in code-behind. So any control should expose public facing properties as DPs to allow for wiring up in XAML. HTH – ΩmegaMan Jun 11 '15 at 12:38
  • I don't think so. You can 'wire' up a regular property by setting it from XAML – Andyz Smith Jun 11 '15 at 12:57
  • And regular properties show up in Microsoft Intellisense the same as dependency properties. Where exactly are you talking about when you say 'not to be shown'? – Andyz Smith Jun 11 '15 at 13:11
  • @AndyzSmith See [When should I use dependency properties in WPF?](http://stackoverflow.com/questions/18592630/when-should-i-use-dependency-properties-in-wpf) – ΩmegaMan Jun 11 '15 at 18:55
  • Yeah that's good. See my answer as well; I include some very concrete examples. – Andyz Smith Jun 11 '15 at 19:08