I have read somewhere that Silverlight is subset of WPF , then why triggers are not used in the silverlight and the States are used. what is difference between these two, Why not the triggers are used in silverlight 3.0
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have read somewhere that Silverlight is subset of WPF , then why triggers are not used in the silverlight and the States are used. what is difference between these two, Why not the triggers are used in silverlight 3.0
Why are triggers not implemented in Silverlight? Ultimately, resource constraints. The Silverlight team were working on a very compressed delivery cycle, and chose to implement the VisualStateManager instead of triggers, because they felt that VSM delivered most of what they needed, and would be much cheaper to implement than the full WPF trigger system.
What’s the difference between them? Triggers are under the control of the template designer: they allow the designer of a (say) Button template to factor in whatever crazy UI states they’re interested in. States are under the control of the control author: the control author has to anticipate which events are important to the display of the control, and assemble these into states.
This article expands on the differences: the article itself argues for the triggers approach, but the comments from John Gossman and Christian Schormann put the case for states.