The default implementation of the ActionMessage.PrepareContext does not enforce thread affinity whenever an action guard changes:
```
PropertyChangedEventHandler handler = null;
handler = (s, e) =>
{
if (string.IsNullOrEmpty(e.PropertyName) || e.PropertyName == guardName)
{
if (context.Message == null)
{
inpc.PropertyChanged -= handler;
return;
}
context.Message.UpdateAvailability();
}
};
```
If a guard changes as a consequence of an asynchronous operation, this line
```
context.Message.UpdateAvailability();
```
will try to manipulate a DependencyObject, throwing an exception.
Wrapping such call into an Execute.OnUIThread seems to me the best approach, considering that property change notification are often silently marshalled on the UI thread (consider the Binding mechanism).
Note that such modification can be implemented as a customization, nevertheless I think that the current approach bears no benefits, while changing the default implementation causes no harm.
Comments: Definitely better than my proposed code. My tests did not show any problem. Is it possible that this fix solves the NRE exception reported by [this work item](http://caliburnmicro.codeplex.com/workitem/290)?
```
PropertyChangedEventHandler handler = null;
handler = (s, e) =>
{
if (string.IsNullOrEmpty(e.PropertyName) || e.PropertyName == guardName)
{
if (context.Message == null)
{
inpc.PropertyChanged -= handler;
return;
}
context.Message.UpdateAvailability();
}
};
```
If a guard changes as a consequence of an asynchronous operation, this line
```
context.Message.UpdateAvailability();
```
will try to manipulate a DependencyObject, throwing an exception.
Wrapping such call into an Execute.OnUIThread seems to me the best approach, considering that property change notification are often silently marshalled on the UI thread (consider the Binding mechanism).
Note that such modification can be implemented as a customization, nevertheless I think that the current approach bears no benefits, while changing the default implementation causes no harm.
Comments: Definitely better than my proposed code. My tests did not show any problem. Is it possible that this fix solves the NRE exception reported by [this work item](http://caliburnmicro.codeplex.com/workitem/290)?
