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 means there's no further confusion around screens being deactivated
without first being activated. This is also closer to the Caliburn.Micro
model.
The Initial state used to be useful for determining the first transition
to Activated, but that turned out not to work, see recent commits.
This caused a regression when screen states were added. Childre of
conductors are deactivated initially, then activated when the parent is
activated. This caused the Initial -> Deactivated transition. Then when
the child was activated, the 'from' state was not Initial, and so the
OnInitialActivate method was not called.
The choice to remain in Initial in this case makes sense: we don't want
to go to Deactivated (and come up with another mechanism for firing
OnInitialActivate), as that would fire OnDeactivate without there being
a corresponding OnActivate, which might mess things up.
This takes the old flag-based state management in Screen, and replaces it
with one based on a ScreenState enum. This also gives a way for
interested parties to query the current state, and for an event which
notifies of any state transition.
This meant combining IActivate, IDeactivate, and IClose. This is a sensible
move: these interfaces were inextricably linked anyway, and separating
them had no advantages and a few disadvantages. If external parties are
using these interfaces directly, then migration is necessary, but these
are usually only used by Conductors
The previous behaviour was to raise an exception unless Execute.Dispatcher
had been explicitly defined. This was to detect cases where the user hadn't
set up Execute correctly, and treat them as errors rather than simply going
ahead with some possibly-unexpected behaviour.
However, since BootstrapperBase sets Execute.Dispatcher automatically, it's
highly unlikely that itwould ever not be set when it needed to be. Exceptions
are design mode and unit tests, both of which want (or can cope with) a
synchronous dispatcher.
Hence the behaviour change. Execute.Dispatcher is a synchronous dispatcher
by default, but is overridden to one that uses Application.Current.Dispatcher
by the bootstrapper if we're in a real application.
Antony Male