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:

As you can see we just added an attached property UseConductor.DocumentConductor that we bind to the current model. Of course the model is a OneActive screen conductor. The behavior take care to connect the document items of the DocumentPane with the screen conductor items. If each screen implements IScreen, the proper Activate/Deactivate/CanClose are called, so we can even handle the case of canceling the close of a dirty document. Here the attached behavior code: An example MainModel can be the following one:

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

By extending the generic helper class proposed for a generic CoRoutine in Caliburn Micro it is easy to create an helper that we can use this way:

public IEnumerable<IResult> SourceChange()
       {
           yield return new CoMethod(() => { PriceDS = CreateDataSource(SelectedSource); });
           NotifyOfPropertyChange(() => this.PriceDS);
           yield return new CoMethod(() => { VolumeDS = CreateDataSource(SelectedSource); });
           NotifyOfPropertyChange(() => this.VolumeDS);
           yield return new CoMethod(() => { Mavg5DS = CalculateMAverage(SelectedSource,5); });
           NotifyOfPropertyChange(() => this.Mavg5DS);
           yield return new CoMethod(() => { Mavg10DS = CalculateMAverage(SelectedSource, 10); });
           NotifyOfPropertyChange(() => this.Mavg10DS);
       }

In a single line we invoke asynchronously a method without having to crate a class implementing IResult. By the way this code is the one that creates the sources for the charts in this blog post.

The helper class is pretty easy:

public class CoMethod:AbstractBackgroundAction
    {
        Action toRun;
        public CoMethod(Action toRun)
        {
            this.toRun = toRun;
        }

        protected override void OnExecute(Caliburn.Micro.ActionExecutionContext context)
        {
            toRun();
        }
    }

It just invoke the action in the BackgroundWorker.

 

As you can see in this discussion, it is not possible to pass a “dotted” expression in an ActionMessage parameter with CM. This is due to the fact that supporting this in a complete and consistent way will force caliburn micro to grow over the micro size. Let’s have a concrete example: we want to invoke an action on the StrokeCollected event of an InkCanvas, and we want to pass the Stroke property of the EventArgs.Here below the wanted syntax:

 <InkCanvas>
        <i:Interaction.Triggers>
            <i:EventTrigger  EventName="StrokeCollected">
                <cl:ActionMessage  MethodName="StrokeCollected" >
                    <cl:Parameter Value="$eventArgs.Stroke">
                        
                    </cl:Parameter>
                </cl:ActionMessage>
            </i:EventTrigger>
        </i:Interaction.Triggers>
    </InkCanvas>

 

If we use the standard behavior, only the $eventArgs portion of the expression is resolved, adding the dot forces CM to just emit the whole string as a parameter. Since we can deal in an application with a simplified strategy, that not necessary cover all scenarios, but is good enough for our purpose, we can redefine the MessageBinder.EvaluateParameter strategy:

var microEvaluator = MessageBinder.EvaluateParameter;
           MessageBinder.EvaluateParameter = (s, t, c) => 
           {
               string[] dotted = s.Split('.');
               if (dotted.Length == 1)
               {
                   // use default CM strategy
                   return microEvaluator(s, t, c);
               }
               else
               {
                   // let's CM happy with any type
                   var first = microEvaluator(dotted[0], typeof(object), c);
                   var dw = Dig(first,dotted.Skip(1));
                   return dw;
               }
                
           };

 

As you can see, we leverage the inner evaluator in the case we have a non dotted separated argument, or for the first chunk of the expression if the dot exists. The Dig function, by the old plain reflection work recursively to return the proper value:

 

        private object Dig(object first, IEnumerable<string> iEnumerable)
        {
            if (iEnumerable.Count() == 0)
                return first;
            else
            {
                PropertyInfo pi = first.GetType().GetProperty(iEnumerable.First());
                if( null == pi )
                {
                    Exception e = new Exception("Property not found:"+iEnumerable.First());
                    LogManager.GetLog(GetType()).Error(e);
                    throw e;
                }
                return Dig(pi.GetValue(first, null),iEnumerable.Skip(1));
            }
        }

As you can see it is pretty simple, despites some fault intolerance, that we can accept since this code will not be part of the library, but is under our control.

Sometimes we want to use some shortcut key for special commands in our application, but the KeyBinding objects works with just routed commands, and so it is not directly usable with Caliburn Micro ( or with many other MVVM strategies ).
In similar situation CM rely on System.Windows.Interactivity.dll, for example when we need to map an event on a Caliburn action we can write:

 

 <Button x:Name="Save" >
           
            <i:Interaction.Triggers>
                <i:EventTrigger EventName="Click">
                    <cl:ActionMessage MethodName="Save" ></cl:ActionMessage>
                </i:EventTrigger>
            </i:Interaction.Triggers>
 </Button>

 

With the code above, we explicitly link the "Click" event from the button to the action calling the metod Save. We can act in a similar way by creating a custom trigger, lets see how.
First look at what we can do it in XAML:

 

<i:Interaction.Triggers>
        <local:InputBindingTrigger>
            <local:InputBindingTrigger.InputBinding>
                <KeyBinding Modifiers="Ctrl" Key="S"/>
            </local:InputBindingTrigger.InputBinding>
            <cl:ActionMessage MethodName="Save"/>
        </local:InputBindingTrigger>
    </i:Interaction.Triggers>

 

We need to declare a class, deriving from TriggerBase in System.Windows.Interactivity in order to fire the action(s) in place of executing a routed command when the user press the proper key gesture. Here the code:

class InputBindingTrigger:TriggerBase<FrameworkElement>,ICommand
    {
        public InputBindingTrigger()
        {

        }
        public InputBinding InputBinding
        {
            get { return (InputBinding)GetValue(InputBindingProperty); }
            set { SetValue(InputBindingProperty, value); }
        }
        public static readonly DependencyProperty InputBindingProperty =
            DependencyProperty.Register("InputBinding", typeof(InputBinding)
            , typeof(InputBindingTrigger)
            , new UIPropertyMetadata(null));
        protected override void OnAttached()
        {
            if (InputBinding != null)
            {
                InputBinding.Command = this;
                AssociatedObject.InputBindings.Add(InputBinding);
            }
            base.OnAttached();
        }

        #region ICommand Members
        public bool CanExecute(object parameter)
        {
            // action is anyway blocked by Caliburn at the invoke level
            return true;
        }
        public event EventHandler CanExecuteChanged = delegate { };

        public void Execute(object parameter)
        {
            InvokeActions(parameter);
        }

        #endregion
    }

 

Very easily we add the InputBinding to the bindings list on the object, and we attach the trigger as a command handler. In the execute function we fire the InvokeActions and it done. Please not the command on the KeyBinding is not required in the markup, since there is virtually any routed command.

Since is very common to use coroutines for spawn non blocking asynchronous activities in Caliburn Micro (CM), I wrote a simple base class than executes the computation via a BackgroundWorker and ensure the result “Completed” is fired on the same thread who start the call, typically, but not necessary, the UI thread. Here the class:

public abstract class AbstractBackgroundAction:IResult
   {
       abstract protected void OnExecute(ActionExecutionContext context);
       #region IResult Members

       public event EventHandler<ResultCompletionEventArgs> Completed = delegate { };

       public void Execute(ActionExecutionContext context)
       {
           using( BackgroundWorker bw = new BackgroundWorker() )
           {
               Exception exception=null;
               bw.DoWork+=(s,e)=>
                   {
                       try
                       {
                           OnExecute(context);
                       }
                       catch (Exception workException)
                       {
                           exception = workException;
                       }
                   };
               bw.RunWorkerCompleted+=(s,e)=>
                   {
                       Completed(this, new ResultCompletionEventArgs { Error=exception });
                   };
               bw.RunWorkerAsync();
           }
       }

       #endregion
   }

By using the RunWorkerCompleted of the BackgroundWorker we ensure to cam back to the original threads who invoked the coroutine step. Implementer has just to override the function OnExecute.

In this post I will describe a – in order to me – little strange behavior in Caliburn Micro ( CM ) that I discovered in my learning by doing sessions. So the scenario is the following, I have an application with a Main model acting as a screen conductor. The conduced screen are visualized as a classical tabbed application. The exercise goal is to define a visual command on the main view and route it to the proper active item, that is I think a quite common scenario. Let me clarify what I want to achieve with an image:

The TabModel class is actually the model connected to the single tab screen. Lets try to do by just naming conventions:

<Button Grid.Row="0" x:Name="Save"  >
                    <Image Source="assets/disk.png"/>
                </Button>

 

Well, it does not work automatically: CM wire just the MainModel, so we need to explicitly re-target the action on the Active child:

<Button Grid.Row="0" x:Name="Save"  cl:Action.TargetWithoutContext="{Binding Path=ActiveItem}">
                    <Image Source="assets/disk.png"/>
                </Button>
Unfortunately message is not routed yet. Let’s try to define the message handler in the main model:

class MainWindowModel:Conductor<object>.Collection.OneActive
   {
       public MainWindowModel()
       {
           Items.Add(new TabModel("Tab 1"));
           Items.Add(new TabModel("Tab 2"));
           Items.Add(new TabModel("Tab 3"));

       }
      
       public void Save()
       { 
       }
   }

Well, it works !

This is because CM creates the poper handler in the main model, so it can route it when we re-target the handler. Since this is probably not the desired behavior, it is probably better to use this strategy instead:

 

<Button Grid.Row="0" x:Name="Save"  

cl:Message.Attach="[Event Click] = [Action Save()]"  

cl:Action.TargetWithoutContext="{Binding Path=ActiveItem}">
                    <Image Source="assets/disk.png"/>
</Button>

By doing this we leave the naming convention strategy, and we explictly declare what we want to do, is better to avoid unpredictable behavior :)

If you are interested in the code for reproducing this check this issue.