Recommended

  • Silverlight 4 Podcast Pack with Tim Heuer
  • Building Modular Silverlight Applications
  • Prism -  10 Things to Know
  • Securing Silverlight Application and WCF Service using ASP.Net Authentication Techniques
  • Model– View – ViewModel in Silverlight
Skip Navigation LinksHome / Search

Search

 
Results Per Page

Found 2 results for Setters.
Date between: <not defined> and <not defined>
Search in: News , Articles , Tips , Shows , Showcase , Books

Order by Publish Date   Ascending Title   Rating  

  • 0 comments  /  posted by  Silverlight Show  on  Nov 02, 2009 (4 weeks ago)
    In this post David Anson explains how to make Silverlight Setters better with the help of SetterValueBindingHelper.

    Back in May, I mentioned that Silverlight 2 and 3 don't support putting a Binding in the Value of a Setter. I explained why this is useful (ex: MVVM, TreeView expansion, developer/designer separation, etc.) and shared a helper class I wrote to implement the intended functionality on Silverlight. My workaround supported setters for normal DependencyPropertys as well as attached ones, so it covered all the bases. It worked well on both flavors of Silverlight and a bunch of you went off and used SetterValueBindingHelper successfully in your own projects.



  • SetterValueBindingHelper makes Silverlight Setters better

    0 comments  /  posted by  Silverlight Show  on  May 08, 2009 (6 months ago)
    Tags: Binding , Styles , Setters

    David Anson will explain you why and how you should use a Setter in your Silverlight application.

    Earlier this week I wrote about the "app building" exercise my team conducted and posted my sample application, a simple organizational hierarchy viewer using many of the controls in the Silverlight Toolkit. One of the surprises I had during the process of building this application was that Silverlight (version 2 as well as the Beta for version 3) doesn't support the scenario of providing a Binding in the Value of a Setter. I bumped into this when I was trying to follow one of the "best practices" for TreeView manipulation - but I soon realized the problem has much broader reach.