EventAggregator Issue with multiple Windows UWP

[RickPons]

Hello I am developing a UWP application I need to send message from Window 1 to Window 2 using eventAggregator I'm using this code to send the message await eventAggregator.PublishOnUIThreadAsync(new myObject());

It's working fine but after to send the message all the properties of my VM have this problem 'Unable to cast COM object of type 'System.ComponentModel.PropertyChangedEventHandler' to class type 'System.ComponentModel.PropertyChangedEventHandler'. Instances of types that represent COM components cannot be cast to types that do not represent COM components; however they can be cast to interfaces as long as the underlying COM component supports QueryInterface calls for the IID of the interface

If I remove the eventAggregator code (for sending the message) my ViewModel and all the properties are working again. I used all of these methods with the same result. PublishOnBackgroundThread PublishOnCurrentThread PublishOnUIThread

[mvermef]

What are you using on the VM to pass the messages, IHandle<T> right?

[nigel-sampson]

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 that the handling view model is updating the UI in it's window?

[RickPons]

@mvermef Yes I'm using IHandle<T>

@nigel-sampson Yes the VM is updating the UI, This application was working fine just with the main window but now I have to open others View Models in another Window I could inject the VM and it is working fine, the only problem is the EventAggregator. If I don't use it my VM works fine.

[nigel-sampson]

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 the view model is confused about the two UI threads.

[RickPons]

@nigel-sampson yes! I tested the code and I can receive the message but the VM crash in the properties with INotifyPropertyChanged is implemented.

[nigel-sampson]

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 view model which thread is the correct one.

Currently Execute holds a reference to what it thinks is the "best" UI thread which is the latest "activated" window. This was mostly built to support Windows 8 apps where they occasionally had a secondary window via something like Share Target. This approach kind of works for UWP with multiple windows. except where there's background messaging / work happening on the non active window.

Execute does have some smarts in that if it detects that it's on a UI thread then it doesn't do anything. So if you can somehow get the message to the correct thread then you're good form there.

One approach would be when creating the new window / view model is to take your own reference to the dispatcher and use it get to the correct thread.

[RickPons]

I tried to use Execute without success I could send the message using the correct Dispatcher of the Window that I want to send the message but after that my VM crash(same all the properties with OnPropertyChanged) I will try to solve this problem by myself extending the functionality of the EventAggregator and I will post the solution here maybe It could be useful to fix the problem with the Framework in this scenario in the future.

[nigel-sampson]

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 to care which thread the message came in on, but can route it to the correct thread for updates.

I'll have a think about what the framework can do, but it's a tough problem.

[RickPons]

What about If I want to send a message from secondary Window to Main Window they have different dispatcher, actually I tried to do that but I can't now I'm trying to avoid using eventAggregator in this scenario.

[nigel-sampson]

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 solution.

If you have small repro of the problem I'm happy to play around with possible solutions.