http://www.jetbrains.com/resharper/webhelp/Code_Analysis__Annotations_in_Source_Code.html

The WindowConductor should be extended to handle activate/deactivate from view.

Window:

• Activatedevent should activate ViewModel
• Deactivated event should deactivate ViewModel (when Window is closing this should be skipped)

ViewHelper.HasBinding(control, UIElement.IsEnabledProperty)

• OpenFile
• SaveFile
• Messenger

Set IsInDesignTool and don't depend on TaskScheduler.FromCurrentSynchronisationContext()

• Coroutine
• EventAggregator
• Screens
• WindowManager
• Win 8.1
• Universal App

When work is outsourced to an async Task it should be possible:

• wait for them on shutdown
• get a list of pending tasks

Also it should be possible to add Tasks to this list by the user.

Features:

• calls a method on a specified object when invoked
• allow to include other parameters using bindings
• maintains the Enabled state of the target control

Similar to Caliburn.Micro ActionMessage

• MessageBox
• FileOpenDialog
• FileSaveDialog

differentiate methods: not everything should be named AsCoTask

when CanCloseAsync() takes more time the user can click on close button or or in task bar.
Then CanCloseAsync() should not be called a second time.

Allow to react on multiple property change events

A lambda expressen (closure with empty capture) is now an instance method on a compiler generated class. The class is decorated with [CompilerGenerated] and [Serializable]. But there is no guaranty that this will always be the case.

How to distinguis lambdas and closures now?

As there is still an issue in Caliburn.Micro, implementing the same code makes no sense.

After switching from VS 2013 to VS 2015 my WP app begins to throw exceptions during runtime.
Here is a simplified code sample:

public class FooViewModel
{
    private ICommand _barCommand;
    public ICommand BarCommand
    {
        get
        {
            if (_BarCommand == null)
            {
                _barCommand = DelegateCommand
                    .For(this)
                    .Execute(viewModel => viewModel.Bar())
                    .Build();
            }
            return _fooCommand;
        }
    }

    private void Bar()
    {
    }
}

Execute method from the code above throws ArgumentException with the message An instance method or closure cannot be used in process of command building.

How to avoid of this issue?

The Weakly.MVVM namespace contains some basic classes that are needed when building an MVVM framework. But it is not complete at all.

The most central part missing is:
How to attach some logic in the ViewModel to an event on a View elements (control)?

The Blend SDK includes:

• CallMethodAction to call a method on the ViewModel
• InvokeCommandAction to attach an ICommand to an event

Caliburn.Micro extends the idea of CallMethodAction with its ActionMessage. Similar did MVVM Light for InvokeCommandAction in EventToCommand.

TODO:

• Add possibility to include information about the origin (source) of the call
• Supply the event arguments
• Allow to include other parameters using bindings (like ActionMessage)

put into doc folder

• remove Caliburn.Micro references
• remove not supported features
• update the docs for latest version
• describe Caliburn.Light specific features

What happens when an exception is thrown in a handler method:

• on same, ui or background thread
• directly in the handler
• in a CoTask
• in an async Task

Features:

• composes one or more ICommands

Similar to Prism 5.0

Features:

• executes a command when invoked
• maintains the Enabled state of the target control based on the CanExecute method of the command

Similar to what Prism 5.0 does.

Caliburn.Micro

Standard

Wich means, no RootFrame gets set, and no INavigationService gets registered with the IoC container.

There has to be a better way than:

private static async void PropagateExceptions(Task task)
{
  await task.ConfigureAwait(false);
}

used in:

• DelegateCommand
• EventAggregator
• CallMethodAction

e.g.

/// <summary>
/// Dispatches exceptions to the UI context when the task threw an unhandled exception.
/// </summary>
/// <param name="task">The Task to be monitored.</param>
public static void DispatchExceptions(Task task)
{
    task.ContinueWith(t => t.PropagateExceptionsTo(_synchronizationContext),
        CancellationToken.None,
        TaskContinuationOptions.ExecuteSynchronously | TaskContinuationOptions.OnlyOnFaulted,
        TaskScheduler.Default);
}

like Caliburn.Micro.ActionMessage uses MessageBinder.SpecialValues

this should not be needed in most cases

• create sealed ParameterCollection (based on FreezableCollection and DependencyObjectCollection)
• remove AttachedCollection

e.g. Bind and ViewLocator should directly use the XAML platform properties

see http://blog.galasoft.ch/posts/2009/09/detecting-design-time-mode-in-wpf-and-silverlight/

only support WPA81 from now on

http://msdn.microsoft.com/en-us/library/system.threading.tasks.task.run%28v=vs.110%29.aspx

We need at max as many tasks as ThreadOptions and not one task per handler.

• Source
• EventArgs
• DataContext (c.Source.DataContext)
• CoroutineExecutionContext

Following is missing:

• Phone-TaskController (as there is an issue copying code from Caliburn.Micro makes no sense)
• VibrateController
• SoundEffectPlayer

use http://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450