There is a bit of confusion out there about which rule to use in which situation when writing rules in your MCML application. I'll just quickly cover the scenarios here...

Default vs Binding Rules

To be honest, you can actually use a Binding rule as a Default rule fairly seamlessly, but it's not really required and adds an (admittedly very small) amount of overhead you don't really need.

The basic difference is that a Default rule is evaluated only ONCE when your application loads. It is never again referenced or used. Binding rules are re-evaluated every time the value of the Source changes. Although pretty insignificant, this means a little bit of memory or a little more time used every time that the property changes.

OK, it's a minor point - but worth bringing up. The second point is a bit more serious.

Changed vs Condition Rules

Some people are likewise confused between the Changed and Condition rules in MCML. The difference in these is pretty simple, but important to know.

A Condition rule can be and often is constantly re-evaluated by Media Center as long as the condition is true. This is excellent for when you are changing the appearance of an object, because you can tell Media Center to make objects visible, brighter, change their colour or text etc. However, because the rules are continually re-evaluated and re-run, there are some things you should NOT do in the Condition rule. You should avoid triggering any event, such as an animation or Invoking a function, that should only happen ONCE.

For this sort of one-shot event, such as mouse clicks, a Command object being invoked or reactions to events from your C# code, you should use the Changed rule.

Changed rules are only run once, when FirePropertyChanged is called. This means that it doesn't matter how long the user chooses to hold the mouse button down or the event remains in it's new value, the rule is only run the one time.

You can further specialise it by adding more conditions.

Let's look at a quick example. In Yougle, I have a "Feedback" section that tells the user what is current going on. When I start a particular function, I set a string to "Starting Embedded Playback", to let the user know that Yougle is working on playing back their media. This triggers the following condition...

<Condition Source="[Feedback.Text]" SourceValue="" ConditionOp="NotEquals">

   <Actions>

     <Set Target="[TextObject.Visible]" Value="true"/>

   </Actions>

</Condition>

The above rule means that for as long as the Feedback's "Text" property anything OTHER than an empty string, the text will be visible.

But what if I want to do something a little more important? What if I wanted to Invoke a function at the same time, but only when the status actually changed to "Starting Embedded Playback"? Remember - this text value could also be any of a hundred other values, so we need to deal with this condition in particular. 

If I put the code in a <Condition>, I could find that my function is Invoked several times. To avoid this, it's much better to put it in a <Changed> rule...

<Changed Source="[Feedback.Text]">

   <Conditions>

      <Equality Source="[Feedback.Text]" Value="Starting Embedded Playback"/>

   </Conditions>

   <Actions>

     <Invoke Target="[MyObject.MyFunction]"/>

   </Actions>

</Condition>

So there you go - using ONE property, but both Changed and Condition rules, you can react to events both when the value changes and while the value is set.

And we've also seen how we can further narrow down rules so that we can deal with a change to a specific value.