Up to now, ScreenExtemsions.TryActivate(newItem) was called
before Conductor.ActiveItem was set to the new item. This commit moves
setting ActiveItem to before TryActivate(newItem) call. This allows for
nested activation - that is, a scenario where newItem can "intercept"
its activation and force parent Conductor to immediately activate
another item inside its OnActivate() override, effectively skipping
newItem without displaying it.
Fixes#140
<EnableDefaultItems>false</EnableDefaultItems> along with
<Compile Include="**\*.cs" Exclude="obj\**" /> and <None Remove="**\*.cs" />
is needed, though.
Annoyingly we need to have two separate projects in two separate directories,
since Framework WPF projects aren't supported in sdk-style csprojs. The
Framework and Core projects also stamp over each others' bin and obj
directories, even if you set IntermediateFilePath, hence the need to put
them in entirely separate places
CommandBinding isn't a DependencyObject, so we can't get its DataContext
or View.ActionTarget -- we can only use the
IRootObjectProvider.RootObject. This should be good enough for most cases,
as these tend to get installed at the root of a window.
Fixes#50
This removes the MessageBoxOptions input to MessageBoxViewModel, and
replaces it with explicit FlowDirection and TextAlignment inputs.
I think this is fair enough - we weren't using most of the members
of MessageBoxOptions, so allowing them to be provided was misleading.
Fixes#12
There's no nice way to make it work alongside CanCloseAsync when you're
in a conductor hierarchy. There will always be difference between how
CanClose and CanCloseAsync behave when there are children which need
to be interrogated as well, and that's confusing.
This will happen if someone takes a concrete class (with no subclasses), uses
ToAllImplementations on it (and InSingletonScope), and wonders why the singleton
registration didn't 'take': the ToAllImplementations didn't create any bindings,
so we fell back to auto-binding the type
It turns out there was a lovely little race with View.ActionTarget, where
either the View.ActionTarget or the corresponding {s:Action} could be
evaluated first. This meant setting View.ActionTarget was risky.
It happened to work in previous releases because the bootstrapper accessed
View.ViewManager, which caused its class ctor to run and somehow caused
View.ActionTarget to be evaluated earlier.
I don't think there's a decent way of getting around this: we can't
guarentee the order in which things in Xaml are going to be evaluated.
That's not the WPF way.
Therefore, only throw exceptions if someone actually clicks the button.
Instead of taking a reference to the Bootstrapper, it takes a configuration
object which is populated by the Bootrapper. This will pave the way for
easier views-in-multiple-assemblies handling in the near future...
This also involved some work to remove registering Stylet's assembly with
the IoC container and the ViewManager. It wasn't really necessary
anyway and just slowed things down.
Antony Male
T.M