Search
Tuesday, January 21, 2020 ..:: Blendblog.net ::.. Register  Login
 Bloggers Minimize

  
 Sponsors Minimize

 Print   
 Users Online Minimize
Membership Membership:
Latest New User Latest: JanaSimpson
New Today New Today: 0
New Yesterday New Yesterday: 0
User Count Overall: 8289

People Online People Online:
Visitors Visitors: 11
Members Members: 0
Total Total: 11

Online Now Online Now:

  
 Welcome to blendblog.net! Minimize

If you are a developer or designer who is creating cutting edge user interface experiences using Microsoft Expression Blend you've just found a great resource!  The purpose of this site is to share our experience with this brand new product.  As with any new piece of software there is a ton to discover.  Bugs will be revealed and workarounds discovered, hopefully this can be a resource to share in the discovery process!

While this site will focus largely on Expression Blend, it will also encompass WPF, Visual Studio, Silverlight, and other .net 3.5 technologies as they relate to the creation of great software.

Please login using your Microsoft LiveID or register a new account.  Doing so will let you comment on any of the blog entries on the site.  We look forward to helping you in your endeavors as well as you helping others in theirs!  We'd love to have more bloggers on our site...if you are interested please register and contact us!

Follow us:


  
 Getting to the bottom of Dependency Properties Minimize
Location: BlogsSean Cullinan    
Posted by: Sean Cullinan 1/22/2008 5:12 PM

I'm now in the thick of working on my company's major commercial application and am building some cool user controls.  I finally had the need to create some dependency properties on one of my controls today but at first I didn't understand why I had to do anything special beyond what I would do in the Winforms realm.  I wanted to hide or show a row in my grid so I simply created a public property ShowStatusRow that did this in code and all worked as expected.  The property even showed up in blend for me to set at design time and I was happy and could've (and maybe should've) gone on my merry way.  But I stopped for a question and asked the question...what is all this stuff I've heard about dependency properties?  I didn't even use them but they keep getting hyped up and written about on the net....obviously I missed something.  What exactly did a dependency property buy me over a standard property?

Well I've spent the better part of a day writing code to illustrate what it buys you.  There are plenty of technical explanations out there, but to keep it simple, here's what I found.  If you want to work with WPF usercontrols as you would have worked with winform user controls then regular properties will suffice.  You will get design time properties that appear in your IDE and can access the properties in your code behind as you would have in a traditional winforms app.  However, if you want to manipulate your controls on storyboards or with WPF data binding you have to use dependency properties. 

To illustrate what I found I created a sample project with 2 different user controls.  The controls just have a label on them with a boolean property that sets the visibility on the label.  On one of the controls the property is a traditional property (IsLabelVisibleRegular).  On the other control I used DependencyProperties (IsLabelVisibleDependency).  I then created a test form that utilizes these controls.
 

  

I used blend to play with the controls to see what the limitations were on a control with just a regular property vs one with a dependency property.  The difference is dramatic...in Blend, the only manipulation I could do to the control with the regular property was a global setting if the IsLabelVisible property.  I could not databind that property (the option was grayed out), and if I tried to do anything with that property on a storyboard it would apply the change I made to the property at the "global" level, not just limiting it to the timeline I was working on.  The only way I could manipulate the property at runtime was in code.

Contrast that to what I could do with my control that utilized the dependency property.  I could now databind the property to the IsChecked status of my toggle button.  I could also set its value in storyboards, and of course I could manipulate it in code just as I could a regular property.

I've attached my sample project.  It contains a clear example of the functional difference of a dependency property vs a standard property.  It is also useful for those looking for information on how to declare and use your dependency properties, how to call them in code, bind to them, and modify them on the storyboard in blend.  I also had to create a class that implements IValueCoverter as I wanted the label on the controls to be visible when the toggle buttons state was not checked and be visible when it was checked...so I had to flip the boolean to get the binding method to work correctly.  Sadly I couldn't find a built in way to do this in Blend so I had to write the BooleanFlipper class myself.

I hope this is useful to someone else out there!

PropertyTester.zip

Permalink |  Trackback

Your name:
Title:
Comment:
Add Comment   Cancel 

  
 Search Minimize

  
 Archive Minimize

  
 Blendblog Survey Minimize
Our next client application will be written using:




Which Tablet Do you expect to buy?





Submit Survey  View Results

 Print   
Copyright 2011 by blendblog.net   Terms Of Use  Privacy Statement
DotNetNuke® is copyright 2002-2020 by DotNetNuke Corporation