Question

I’m using Caliburn Micro to create a Visual Studio style interface for my application.

The user could have multiple errors in multiple windows which are all shown on an ‘errors’ view which is docked at the bottom of my application. I’ve managed to implement a nice notification mechanism so that when changes are made to any document, the errors VM is notified and queries the source object.

I’m having trouble, however, in figuring out how to get a double-click to navigate to the source of the error.

Imagine I have bound ‘description’ to a textbox on my document view and this provides a ‘description is required’ validation message. Double clicking the message should navigate the user to the document in question and focus on the textbox.

The validation objects that provide the messages already contain a reference to the viewmodel (as an IViewAware interface) which allows me to call GetView() to get a reference to the view. I’ve tried using this approach to enumerate the bindings on my view and find the controls that are bound to a particular property, though this is very slow and more of a brute force – pot luck approach

Does anyone have any recommendations on approaches to this problem? My only other thought is to pass responsibility of the ‘focus’ action to the view itself and have that decide how to handle a request for navigation to a certain property – maybe using attached properties to identify particular controls by a unique property identifier. The application could cache this list in a dictionary to make things quicker (all the processing done up front as the app is loading)

I assume Visual Studio implements this quite easily for the standard code editor window, since it just needs a line number to jump to the right place..

Answer 1

Ok so after a couple of hours messing about with this I’ve come to a solution which seems to work ok. I’ve implemented an interface class for my views which allows them to navigate.

The basic setup is:

ErrorsViewModel – receives notifications that a business object needs requerying for errors and manages the list of errors and when it needs to query (so that any work can be done on a background thread to prevent locking the UI)

WorkspaceViewModel – the main workspace VM that hosts the tool panes and documents

ICanNavigate – interface that the views will impelement to decide how to handle navigation arguments

NavigationEventMessage – the message that is sent to the event aggregator to provide a navigation notification and arguments

The ErrorsViewModel receives an event message from another VM via the event aggregator and eventually queries the object (when it can). Once the errors are gathered, it shows the items in the view (in a grid control at the moment).

When the user double clicks on a row a NavigationEventMessage is dispatched which contains some arguments such as the view that dispatched it and the target business object etc. It is handled by..

1) The WorkspaceViewModels view. This allows it to bring the correct document into activation by looking at the DataContext of each object and checking if it matches the view passed in the message

2) The target documents view, the view decides what to highlight/show/seek to based on the arguments sent in the message

This seemed to be the most logical way to separate the VM from the View as the ViewModels still have no coupling with the views. The view just implements the interface, and the VM calls it if it’s there and passes in the args.