3

I have been trying to use System.Windows.Interactivity.Interaction with WPF from MS Expression Blend SDK for .NET 4. The problem is that I can't find the Interaction.Triggers attached property there. The Interaction class exists, but I can see only 4 members in it: Equals, GetBehaviors, GetTriggers, ReferenceEquals. I looked at the properties of the reference to System.Windows.Interactivity.dll in my project and found that the path is

"C:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries\System.Windows.Interactivity.dll"

So, I opened the file on that path with IL Disassеmbler and found that the Interaction class actually has the Triggers attached property, but the property is declared as private! Then I opened the same dll in \Lib\Desktop directory of Prism SDK and found the same situation there. The versions of these dlls are 2.0.20525.0. There is also a System.Windows.Interactivity.xml file with the System.Windows.Interactivity dlls. In it I found following about TriggersProperty:

This property is not exposed publicly. This forces clients to use the GetTriggers and SetTriggers methods to access the collection, ensuring the collection exists and is set before it is used.

But I didn't find any SetTriggers methods there. BTW, Silverlight's Interaction has TriggersProperty as a public member.

I have seen many examples using Interaction.Triggers with WPF and I assume there shouldn't be any problems. What am I doing wrong?

XanderMK
  • 371
  • 1
  • 2
  • 13

1 Answers1

5

Well there's definitely something strange going on. Here's what I found:

  • Using System.Windows.Interactivity.dll from Prism 4.1, Interaction.TriggersProperty shows up as a public field in the object browser within VS2010.
  • The same assembly shows that TriggersProperty is a private field in ILDASM.
  • Using System.Windows.Interactivity.dll from Blend SDK for .NET 4, TriggersProperty does not display in the object browser.
  • The same assembly shows that TriggersProperty is a private field in ILDASM.

I don't have an explanation. However, I can say that if you simply write <i:Interaction.Triggers> in your WPF XAML and reference System.Windows.Interactivity.dll from Prism 4.1, it just works as expected.

I tried checking some other framework classes to see if it's a bug in ILDASM, but those all presented with the correct access modifier. So I don't know why the Prism version works, but it seems to do just that. I haven't tried the straight up Blend SDK version as I've not had a need for it.

edit: A little more info: Digging around with Resharper, I found that Interaction.TriggersProperty is not used anywhere. However, Interaction.GetTriggers is used all over my WPF code. So I'm betting that there's some XAML binding reflection magic that makes this all work. I say "magic" because I don't understand it. Apparently the Blend SDK folks think you should only use the Behaviors and Triggers attached property from XAML, but the Prism folks think you should be able to use it from code as well.

Mike Post
  • 6,355
  • 3
  • 38
  • 48
  • I guess there is a typo in the first or in the second bullet. Things cannot be public in object browser and private in ILDASM, or they are two different libraries. – XanderMK May 02 '12 at 13:45
  • 1
    There is no typo. It shows up differently in object browser and ILDASM. They are most definitely the same files being loaded into the two tools. Try it for yourself if you don't believe me. – Mike Post May 02 '12 at 19:15
  • Yes, this works. I must have mistyped something the first time. Looks like the Interaction.GetTriggers first checks if the Interaction.Triggers property has been set and sets it otherwise. And the Interaction.GetTriggers is the only legal way in WPF to get obtain Interaction.Triggers. BTW, for some reason the name of Interaction.Triggers property is "ShadowTriggers". It's true in WPF, not sure about Silverlight. – XanderMK May 09 '12 at 10:07