Nigel Sampson

@StephenWard I don't think it's a major expansion, we won't be adding more capabilities to `Message.Attach`, just a better resolver for which method to call when there are overloads. Thinking...

Can you expand on that, it's nothing something I've used before. But platform availability would certainly be a concern.

Thanks for that, will look it over, may be a bit of sledgehammer to crack a nut, but a definite possibility.

It's certainly an interesting bug, I'm still looking at what the ultimate cause is. It's definitely something around the collapsed nature of the view as removing the `Task.Delay` or default...

Interesting, the problem will be the issue that there are two UI threads, however I'd expect the other methods such as `PublishOnCurrentThread` not to have that problem. Can I assume...

Curious if you remove the update UI work whether the message is properly sent to the secondary view model with `PublishOnCurrentThread`. I have a feeling the message is arriving, but...

Thanks, the problem is around the dispatching property change notifications to the UI thread when you have multiple UI threads. Unfortunately there's no real way to tell for any given...

I'd consider each window view model capturing their dispatcher. So in the handle of the message dispatching all the UI codes to the captured dispatcher. This way you don't need...

I really don't think the problem is with the event aggregator itself, but just dealing with "property changed notifications" on the current UI thread, you'll have problems with any messaging...

I'm assuming this is Windows 8 or Windows Phone 8.1? Since you're passing sender, can you cast that to the DatePicker and check the Date property on that. I'm wondering...