As we know the Caliburn Micro library implements a screen conductor to handle multiple screen models with only one active, typically used for tabbed views, that is easy to implement by deriving your model from Conductor<IScreen>.Collection.OneActive. This works out of the box with the standard tab control, but it is not possible to use it for example with the tabbed documents in AvalonDock. The only solution I found, that for some reason I will say below, is this one. I don’t like this solution because it force to write code inside the view, that is not acceptable in a pure MVVM solution, so I preferred to insulate the code in an attached behavior. In addition the presented solution will works correctly with the Activate/Deactivate/CanClose strategy on each document. We just need to modify the view markup as in the example below:

( we just add some random document to see how it behave )

And here below an example of a single screen  model:

So we have the conductor, without touching the view code, and without creating a custom screen conductor.

If you plan to use the Caliburn Micro convention with buttons contained in a Fluent Ribbon you will notice that it does not works out of the box. This is because the default BindingScope.GetNamedElements does not dig inside the ribbon to looks for named control. The solution that worked for me is to modify the default behavior as swown below:

In the overridden Configure function:

…

defaultElementLookup = BindingScope.GetNamedElements; BindingScope.GetNamedElements
= new Func<System.Windows.DependencyObject, IEnumerable<System.Windows.FrameworkElement>>(
k => { List<FrameworkElement>
namedElements = new List<FrameworkElement>();
namedElements.AddRange(defaultElementLookup(k)); Fluent.Ribbon ribbon
= LookForRibbon(k); if( null !=
ribbon ) AppendRibbonNamedItem(ribbon, namedElements); return namedElements;
} ); 

…

We need to define defaultElementLookup into the boot class as:

          Func<DependencyObject, IEnumerable<FrameworkElement>>
defaultElementLookup; I saved the standard GetNamedElement function because I use
it to look for the control the default way, and to look for the controls inside the
Ribbon too.

Here the function LookForRibbon, that just dig into the visual tree to search for a ribbbon ( if any ):

          private Fluent.Ribbon LookForRibbon(DependencyObject k)
{ Fluent.Ribbon foundRibbon = null; var contentControl
= k as ContentControl; if (null !=
contentControl) { var child = contentControl.Content as DependencyObject; if( null !=
child ) return LookForRibbon(child); } for (int i
= 0; i < VisualTreeHelper.GetChildrenCount(k);
++i) { var child = VisualTreeHelper.GetChild(k,
i); foundRibbon = child as Fluent.Ribbon; if (null !=
foundRibbon) { return foundRibbon; } else {
foundRibbon = LookForRibbon(child); if (null !=
foundRibbon) return foundRibbon; } } return
null; } 

As you guess, the function stops at the first found ribbon so we suppose there is just one ribbon for view ( quite reasonable )

As we have the ribbon we can look for the elements inside and append to the list with this function:

          private void AppendRibbonNamedItem(Fluent.Ribbon ribbon, List<FrameworkElement>
namedElements) { foreach (var ti in ribbon.Tabs)
{ foreach (var group in ti.Groups)
{ namedElements.AddRange(defaultElementLookup(group)); } } } 

So we look inside each ribbon group and we treat these as Caliburn would do.

The current ( trunk ) implementation of Caliburn Micro introduces a new element in the phase of obtaining the view type name from the model name. The name of the View type is obtained from the name of the ViewModel type by applying a series of rules based on RegEx match and replace patterns. These rules has some defaults values, but others can be added externally by calling

NameTransformer.AddRule

There is an important default that is given by the following pattern:

NameTransformer.AddRule("Model$", string.Empty); 

This is the rule that allow old model view naming convention works properly.

If you have some not up-to-date trunk version you can experience some problem, have a look at this discussion. The current doc of NameTrasformer is the source code of the ViewLocator and the ViewModelLocator from which you can derive what conventions are applied.