views:

189

answers:

1

I have a wpf gui which displays a list of information in separate window and in a separate thread from the main application. As the user performs actions in the main window the side window is updated. (For example if you clicked page down in the main window a listbox in the side window would page down).

Right now the architecture for this application feels very messy and I'm sure there is a cleaner way to do it. It looks like this:

Main Window contains a singleton SideWindowControl which communicates with an instance of the SideWindowDisplay using events - so, for example, the pagedown button would work like:

1) the event handler of the button on the main window calls SideWindowControl.PageDown()

2) in the PageDown() function a event is created and thrown.

3) finally the gui, ShowSideWindowDisplay is subscribing to the SideWindowControl.Actions event handles the event and actually scrolls the listbox down - note because it is in a different thread it has to do that by running the command via Dispatcher.Invoke()

This just seems like a very messy way to this and there must be a clearer way (The only part that can't change is that the main window and the side window must be on different threads). Perhaps using WPF commands?

I'd really appreciate any suggestions!! Thanks

A: 

You could try to use a Mediator/Messenger to send messages between the Views or ViewModels. You can take a look at the implementation that comes with MVVM Light, to see how it's done.

The idea would be something like this:

  1. Main window executes action
  2. Action fires a command in a ViewModel
  3. Command method sends a message to the Messenger
  4. Side window ViewModel subscribes to it
  5. An event is fired on the side window VM when the message arrives; side window acts accordingly.

Another option is to bind both controls to the same ViewModel, which would then contain all the commands and coordinate the actions.

robertos