caliburnmicro Issue Tracker Rss Feed

Created Unassigned: Remove IHaveDisplayName from IScreen and Screen [315]

dhilgarth — Wed, 22 May 2013 13:29:22 GMT

I don't see why `IScreen` inherits `IHaveDisplayName`.
Most of the time, you *don't* want to set the title of a window from the ViewModel, just like you normally wouldn't set the title of the button from the VM.

This interface is incredibly easy to implement, so there is really no reason to implement it by default.
Right now, I have to basically re-implement `Screen` without that interface to stop it from hijacking and overwriting the title defined in XAML. Furthermore, the current default (the type of the view model) is never a good value for a title.

I see not a single reason for having that interface implemented in `Screen`.

Commented Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

cshepherd — Wed, 22 May 2013 08:36:01 GMT

Edited Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

tibel — Wed, 22 May 2013 08:01:52 GMT

Commented Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

tibel — Wed, 22 May 2013 08:01:33 GMT

Commented Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

cshepherd — Fri, 17 May 2013 13:17:07 GMT

We have the option to use the original coroutines or using C#5 async/await.

However, taking a class based on IResult and calling AsResult on it to return a Task for async/await doesn't pass it through IoC.BuildUp to inject properties (IWindowManager etc.).

For consistency could we pass it through IoC.BuildUp before execution or is there some other reason for this?
Comments: In standard CM Coroutines the IResult doesn't pass through IoC.BuildUp until it's been yielded. If you use AsTask() then it never goes through this. CM seems to wrap the Result in a new Task and I think that it could be passed through IoC.BuildUp in there. Otherwise, you can't really use Results interchangeably with either method. For instance, I have a ShowDialogResult that needs the IWindowManager injected. At the moment I'd have to pass this in through the constructor from the VM or manually pass the result to IoC.BuildUp before calling 'await' on it.

Commented Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

tibel — Fri, 17 May 2013 10:30:55 GMT

Created Unassigned: Result turned into a Task using ExecuteAsync is not passed through IoC. [314]

cshepherd — Thu, 16 May 2013 16:21:20 GMT

Created Task: Modifying the IoC api for testability / usability [313]

McDonnellDean — Tue, 14 May 2013 20:35:25 GMT

The service locator, IoC, is inherently hard to test and it's public facing API is sloppy. This is because not all lambda's are wrapped for easy consumption.

My proposal is to add following missing Methods

```
IEnumerable<T> GetAll<T>();
Void BuildUp();
```

I would also like to change BuildUp to BuildUpInstance. This would be in line with the GetInstance and GetAllInstances lambda's However as this is a public facing method it could be considered a breaking change.

Finally I would like to change the XML docs of the Lambda's to make it clear that they are points of configuration, and to use the methods were ServiceLocation is required.

This would enable a better user and testing story. It would also mean that better exceptions could be thrown if any of the delegates are null as this usually means they have not been set up correctly.

Commented Issue: PropertyChangedBase.NotifyPropertyChange always dispatch handlers on the UI thread [291]

BladeWise — Tue, 14 May 2013 14:37:26 GMT

The current implementation of the PropertyChangedBase.NotifyPropertyChanged always dispatches events handlers on the UI thread. Such behavior is pretty much extreme, and not intuitive.
I am aware of the fact that some pieces of code could rely on such a feature (see [this issue](http://caliburnmicro.codeplex.com/workitem/286) about ActionMessage), but in such cases the handlers should be responsible to ensure thread affinity, not the caller.

The current behavior can lead to unexpected and hard to track UI slow-downs, expecially in case the new C# async feature is used.

I reamember that early versions of the Xaml engine (CTP or alike) did not ensure thread affinity for property change notification, is this the reason for such a choice?

Comments: If this design tries to address the lacking of thread-affinity support in platforms other than WPF, then I think that such code should be platform-specific, and avoided in WPF. On the contrary, if it is a way to avoid some pitfalls of multithreading, I would like to be able to disable this feature, without being forced to modify the sources and recompile everything. Maybe, adding a static boolean property to _PropertyChangedBase_ (let's call it _EnforceThreadAffinity_) to enable/disable this feature, could suffice: the standard behaviour for all platform would be the same, but the developer can decide to configure CM so that it does not interfere (and I happily take advantage of both CM standard classes and WPF thread-affinity model :)). On a final note, it would be better in my opinion to mark the function ``` void OnPropertyChanged(PropertyChangedEventArgs e) ``` as protected (and maybe virtual), otherwise, it is not possible to override the current behavior even through inheritance (there is no way to raise the _PropertyChanged_ event, without using the dispatcher). In case you want to avoid that developers accidentally use the _OnPropertyChanged_ directly, it is possible to mark it with a ``` [EditorBrowsable(EditorBrowsableState.Never)] ```

Commented Issue: PropertyChangedBase.NotifyPropertyChange always dispatch handlers on the UI thread [291]

McDonnellDean — Tue, 14 May 2013 12:36:30 GMT

The current implementation of the PropertyChangedBase.NotifyPropertyChanged always dispatches events handlers on the UI thread. Such behavior is pretty much extreme, and not intuitive.
I am aware of the fact that some pieces of code could rely on such a feature (see [this issue](http://caliburnmicro.codeplex.com/workitem/286) about ActionMessage), but in such cases the handlers should be responsible to ensure thread affinity, not the caller.

The current behavior can lead to unexpected and hard to track UI slow-downs, expecially in case the new C# async feature is used.

I reamember that early versions of the Xaml engine (CTP or alike) did not ensure thread affinity for property change notification, is this the reason for such a choice?

Comments: In general this sort of implementation detail will always make somebody unhappy. I was not around for the original decision but I can understand why it was made. The main candidates for INPC scaffolding are ViewModels and thread affinity is not guarantied in all places. Ultimately I find it is easier to spin off a thread manually that it is to have to sync back to the dispatcher over and over. I personally would not like to see this changed as it means that users would have to explicitly handle UI thread syncing in some cases, but not all. This is messy in my opinion, it is better that all INPC work is done on the UI thread and you can commonly override it as needed.

Commented Unassigned: [Dev Question] Action guard method re-evaluation [312]

BladeWise — Mon, 13 May 2013 11:20:44 GMT

I wanted to get opinions from the dev's on items like below see https://caliburnmicro.codeplex.com/discussions/442668 for original source.

On the one hand something like this could be integrated into Caliburn.Micro proper, on the other hand it could make more sense for the original author to package it up as an recipe.

Thoughts?

Every now and then, there is a new user that asks how to trigger availability update for action guards implemented as methods. I am aware that such methods are re-evaluated every time a parameter changes, but there are some cases where the evaluation of a guard depends on both the parameters and the internal state of the class providing the action. In such a scenario, it can be useful to have a way to forcefully request an availability update on the action.

I decided to provide a possible solution, involving a simple naming convention and the use of specific events: consider and action called 'Execute(...)' and the associated method guard 'CanExecute(...)'; my idea is to modify the PrepareContext implementation to check for the existence of a specific event, called 'ReEvaluateCanExecute' and, if available, attach to it and invoke UpdateAvailability whenever the event is invoked.
Since PrepareContext is an extensibility point, this feature can be easily added, without modifying the current CM code base.

The actual implementation is provided below:
``` C#
namespace ActionGuardSample
{
#region Namespaces
using System;
using System.ComponentModel;
using System.Linq;
using System.Reflection;
using Caliburn.Micro;
using Action = System.Action;

#endregion

/// <summary>
/// Static class used to provide Caliburn Micro extensions.
/// </summary>
public static class CaliburnMicroExtensions
{
#region Static Methods
/// <summary>
/// Prepares the context.
/// </summary>
/// <param name="context">The context.</param>
private static void PrepareContext(ActionExecutionContext context)
{
ActionMessage.SetMethodBinding(context);
if (context.Target != null && context.Method != null)
{
var targetType = context.Target.GetType();
var guardName = string.Format("Can{0}", context.Method.Name);
var guard = TryFindGuardMethod(context);
if (guard == null)
{
var inpc = context.Target as INotifyPropertyChanged;
if (inpc == null)
return;
guard = targetType.GetMethod(string.Format("get_{0}", guardName));
if (guard == null)
return;
var handler = (PropertyChangedEventHandler)null;
handler = ((s, e) =>
{
if (string.IsNullOrEmpty(e.PropertyName) || e.PropertyName == guardName)
{
((Action)(() =>
{
var message = context.Message;
if (message == null)
inpc.PropertyChanged -= handler;
else
message.UpdateAvailability();
})).OnUIThread();
}
});
inpc.PropertyChanged += handler;
context.Disposing += (s, e) => inpc.PropertyChanged -= handler;
context.Message.Detaching += (s, e) => inpc.PropertyChanged -= handler;
context.CanExecute = () => (bool)guard.Invoke(context.Target, MessageBinder.DetermineParameters(context, guard.GetParameters()));
}
else
{
var updateEventName = string.Format("ReEvaluate{0}", guardName);
var updateEvent = targetType.GetEvent(updateEventName);
if (updateEvent != null)
{
var target = context.Target;
EventHandler handler = null;
handler = (s, e) => ((Action)(() =>
{
var message = context.Message;
if (message == null)
updateEvent.RemoveEventHandler(target, handler);
else
message.UpdateAvailability();
})).OnUIThread();
updateEvent.AddEventHandler(target, handler);
context.Disposing += (s, e) => updateEvent.RemoveEventHandler(target, handler);
context.Message.Detaching += (s, e) => updateEvent.RemoveEventHandler(target, handler);
}

context.CanExecute = () => (bool)guard.Invoke(context.Target, MessageBinder.DetermineParameters(context, guard.GetParameters()));
}
}
}

/// <summary>
/// Tries to find the guard method.
/// </summary>
/// <param name="context">The context.</param>
/// <returns>The guard method.</returns>
private static MethodInfo TryFindGuardMethod(ActionExecutionContext context)
{
var name = string.Format("Can{0}", context.Method.Name);
var method = context.Target.GetType().GetMethod(name);
if (method == null)
return null;
if (method.ContainsGenericParameters)
return null;
if (typeof(bool) != method.ReturnType)
return null;
var methodParameters = method.GetParameters();
var contextMethodParameters = context.Method.GetParameters();
if (methodParameters.Length == 0)
return method;
if (methodParameters.Length != contextMethodParameters.Length)
return null;
return methodParameters.Zip(contextMethodParameters, (x, y) => x.ParameterType == y.ParameterType).Any(x => !x) ? null : method;
}

/// <summary>
/// Enables support for action guard methods re-evaluation, through a specific event naming convention.
/// </summary>
public static void EnableActionGuardMethodReEvaluateSupport()
{
ActionMessage.PrepareContext = PrepareContext;
}
#endregion
}
}
```
You can download a working sample [here](http://www.mediafire.com/?irqiiq9bvbn41x4).
Comments: As I said, it is quite easy to plumb this code as an extension, but I feel that it could be part of the CM code base, since it places action guards on pair with property guards, solving a huge limitation: action guards are updated only if a parameter changes, and there is no clean way to force an update from the view-model (raising a property changed for a parameter is a possible workaround, but feels quite dirty...).

Edited Unassigned: [Dev Question] Action guard method re-evaluation [312]

McDonnellDean — Sun, 12 May 2013 11:50:42 GMT

Created Unassigned: [Dev Question] Action guard method re-evaluation [312]

McDonnellDean — Sun, 12 May 2013 11:49:32 GMT

I wanted to get opinions from the dev's on items like below.

On the one hand something like this could be integrated into Caliburn.Micro proper, on the other hand it could make more sense for the original author to package it up as an recipe.

Thoughts?

Every now and then, there is a new user that asks how to trigger availability update for action guards implemented as methods. I am aware that such methods are re-evaluated every time a parameter changes, but there are some cases where the evaluation of a guard depends on both the parameters and the internal state of the class providing the action. In such a scenario, it can be useful to have a way to forcefully request an availability update on the action.

I decided to provide a possible solution, involving a simple naming convention and the use of specific events: consider and action called 'Execute(...)' and the associated method guard 'CanExecute(...)'; my idea is to modify the PrepareContext implementation to check for the existence of a specific event, called 'ReEvaluateCanExecute' and, if available, attach to it and invoke UpdateAvailability whenever the event is invoked.
Since PrepareContext is an extensibility point, this feature can be easily added, without modifying the current CM code base.

The actual implementation is provided below:
``` C#
namespace ActionGuardSample
{
#region Namespaces
using System;
using System.ComponentModel;
using System.Linq;
using System.Reflection;
using Caliburn.Micro;
using Action = System.Action;

#endregion

/// <summary>
/// Static class used to provide Caliburn Micro extensions.
/// </summary>
public static class CaliburnMicroExtensions
{
#region Static Methods
/// <summary>
/// Prepares the context.
/// </summary>
/// <param name="context">The context.</param>
private static void PrepareContext(ActionExecutionContext context)
{
ActionMessage.SetMethodBinding(context);
if (context.Target != null && context.Method != null)
{
var targetType = context.Target.GetType();
var guardName = string.Format("Can{0}", context.Method.Name);
var guard = TryFindGuardMethod(context);
if (guard == null)
{
var inpc = context.Target as INotifyPropertyChanged;
if (inpc == null)
return;
guard = targetType.GetMethod(string.Format("get_{0}", guardName));
if (guard == null)
return;
var handler = (PropertyChangedEventHandler)null;
handler = ((s, e) =>
{
if (string.IsNullOrEmpty(e.PropertyName) || e.PropertyName == guardName)
{
((Action)(() =>
{
var message = context.Message;
if (message == null)
inpc.PropertyChanged -= handler;
else
message.UpdateAvailability();
})).OnUIThread();
}
});
inpc.PropertyChanged += handler;
context.Disposing += (s, e) => inpc.PropertyChanged -= handler;
context.Message.Detaching += (s, e) => inpc.PropertyChanged -= handler;
context.CanExecute = () => (bool)guard.Invoke(context.Target, MessageBinder.DetermineParameters(context, guard.GetParameters()));
}
else
{
var updateEventName = string.Format("ReEvaluate{0}", guardName);
var updateEvent = targetType.GetEvent(updateEventName);
if (updateEvent != null)
{
var target = context.Target;
EventHandler handler = null;
handler = (s, e) => ((Action)(() =>
{
var message = context.Message;
if (message == null)
updateEvent.RemoveEventHandler(target, handler);
else
message.UpdateAvailability();
})).OnUIThread();
updateEvent.AddEventHandler(target, handler);
context.Disposing += (s, e) => updateEvent.RemoveEventHandler(target, handler);
context.Message.Detaching += (s, e) => updateEvent.RemoveEventHandler(target, handler);
}

context.CanExecute = () => (bool)guard.Invoke(context.Target, MessageBinder.DetermineParameters(context, guard.GetParameters()));
}
}
}

/// <summary>
/// Tries to find the guard method.
/// </summary>
/// <param name="context">The context.</param>
/// <returns>The guard method.</returns>
private static MethodInfo TryFindGuardMethod(ActionExecutionContext context)
{
var name = string.Format("Can{0}", context.Method.Name);
var method = context.Target.GetType().GetMethod(name);
if (method == null)
return null;
if (method.ContainsGenericParameters)
return null;
if (typeof(bool) != method.ReturnType)
return null;
var methodParameters = method.GetParameters();
var contextMethodParameters = context.Method.GetParameters();
if (methodParameters.Length == 0)
return method;
if (methodParameters.Length != contextMethodParameters.Length)
return null;
return methodParameters.Zip(contextMethodParameters, (x, y) => x.ParameterType == y.ParameterType).Any(x => !x) ? null : method;
}

/// <summary>
/// Enables support for action guard methods re-evaluation, through a specific event naming convention.
/// </summary>
public static void EnableActionGuardMethodReEvaluateSupport()
{
ActionMessage.PrepareContext = PrepareContext;
}
#endregion
}
}
```
You can download a working sample [here](http://www.mediafire.com/?irqiiq9bvbn41x4).

Closed Unassigned: AppBootstrapper: .Configure() not reliable if marked as async, Windows Phone [311]

tibel — Sat, 04 May 2013 07:38:36 GMT

Hi all,

I had to mark the .Configure method of the bootstrapper as async since there is some file system access going on.

Now, every 3-10 launches the app will not come up correctly as CM does not bind the view model in time.

I know, because I introduced a static property on the bootstrapper that is set once .Configure() has run to the end. I checked that property in the code-behind of the first page (RootPageView.xaml). It sometimes comes up as unset.

The first page of the app comes up very quickly (no content, no code-behind). It's only used to jump into the application (cannot change this).

Do you have any suggestions?

Can I put async Func<Task<T>> into the container so that I do not have to resolve the types in the bootstrapper itself? An example would be appreciated.

Or should I handle the async dependency myself somewhere in the app?

I appended the precise code.

Windows Phone 8, CM 1.4.x and 1.5.x

The code:
```
protected override async void Configure()
{
container = new PhoneContainer(RootFrame);

container.RegisterPhoneServices();

var state = await AppState.Retrieve();

if (state != null) // Not set in designer
{
var settings = state.GetCurrentSettings();

if (settings == null)
{
var firstSettings = state.KnownServerLogins.First();

await state.SetCurrentSettings(firstSettings);

settings = state.GetCurrentSettings();
}

var context = new AppContext(state, () => new HttpClientWP8(), new NetworkingWP7(), new JsonSerializerWP7());

container.RegisterInstance(typeof(PhoneApplicationFrame), null, RootFrame);
container.RegisterInstance(typeof(AppContext), null, context);
container.RegisterInstance(typeof(IUniqueIntProvider), null, state);
container.RegisterInstance(typeof(IServerSettings), null, settings);
container.RegisterHandler(typeof(IRelativeFileSystem), null, c => new FileSystemWinRT());
container.RegisterHandler(typeof(IJsonSerializer), null, c => new JsonSerializerWP7());
container.RegisterSingleton(typeof(Space), null, typeof(Space));

var space = (Space)container.GetInstance(typeof(Space), null);
context.CurrentSpace = space;

container.Singleton<RootPageViewModel>();
container.PerRequest<MainPageViewModel>();
}

AddCustomConventions();

Container = container;
}
```

Thanks,
Best,
Tobias
Comments: Not a CM issue

Commented Feature: Make Portable Libraries [259]

tibel — Thu, 02 May 2013 16:53:34 GMT

For v2 we need to refactor to portable libraries.
Comments: .NET 4.0 will not be supported by portable version, see https://twitter.com/davkean/status/329658035490418688

Commented Feature: Make Portable Libraries [259]

tibel — Wed, 01 May 2013 11:10:11 GMT

For v2 we need to refactor to portable libraries.
Comments: Last message is true, when portable project includes .NET 4.0 target. Other combinations work.

Commented Feature: Make Portable Libraries [259]

tibel — Wed, 01 May 2013 10:54:07 GMT

For v2 we need to refactor to portable libraries.
Comments: This issue is still blocked: _INotifyCollectionChanged_ is not supported by portable projects yet.

Commented Unassigned: AppBootstrapper: .Configure() not reliable if marked as async, Windows Phone [311]

tibel — Wed, 01 May 2013 06:00:44 GMT

Commented Unassigned: AppBootstrapper: .Configure() not reliable if marked as async, Windows Phone [311]

tskarman — Sun, 28 Apr 2013 22:41:30 GMT

Commented Unassigned: AppBootstrapper: .Configure() not reliable if marked as async, Windows Phone [311]

tskarman — Sun, 28 Apr 2013 22:40:31 GMT