Commit Graph

766 Commits

Author SHA1 Message Date
Antony Male 044f94873a Minor tidying, fix stylecopy violations 2015-10-07 09:27:26 +01:00
Antony Male 545a334369 Remove bad reference to FodyTargets.xml 2015-10-06 12:57:09 +01:00
Antony Male fdfaefa94e Implement another mechanism of backup ActionTarget, using IRootObjectProvider 2015-10-06 12:57:08 +01:00
Antony Male 54cd9cf18f Revert the BindingProxy stuff
Trying to do this properly turns out to just be unworkable
2015-10-06 11:54:33 +01:00
Antony Male 35ecc551a3 Merge branch 'feature/binding-and' into develop
* feature/binding-and:
  Use multi-binding in bootstrapper
  Slightly more testing, and docs
  Start getting towards something that works...
  WIP: Support 'And' to bind multiple services to type
2015-10-03 17:06:23 +01:00
Antony Male 764cfe0b39 Use multi-binding in bootstrapper 2015-10-03 17:06:12 +01:00
Antony Male df7e024bf5 Slightly more testing, and docs 2015-10-03 17:06:11 +01:00
Antony Male bd18b94e82 Start getting towards something that works... 2015-10-03 17:06:11 +01:00
Antony Male 498597c0a6 WIP: Support 'And' to bind multiple services to type 2015-10-03 17:06:10 +01:00
Antony Male 447f68f1f0 Only throw on click if action not found
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.
2015-10-03 15:50:55 +01:00
Antony Male 9263753600 Get rid of dependency on albacore 2015-09-25 15:28:11 +01:00
Antony Male 81f256d231 Move away from separate ViewManagerConfig class 2015-09-25 15:19:23 +01:00
Antony Male d265bb3ba2 Fix typo in BuilderBindingBase 2015-09-25 13:47:36 +01:00
Antony Male 29b41c59ce Fix test coverage generation 2015-09-25 11:16:56 +01:00
Antony Male 667564c3af Add support for customising 'View' and 'ViewModel' suffixes in ViewManager 2015-09-25 11:16:50 +01:00
Antony Male 8a6f010fbb Add support for namespace transformations to ViewManager 2015-09-25 10:57:46 +01:00
Antony Male 3dd1ec2bfe Ensure that ViewManagerConfig properties cannot be null 2015-09-25 10:43:17 +01:00
Antony Male 000a77c4a9 Make looking up a view type slightly cheaper 2015-09-25 10:39:19 +01:00
Antony Male 7bc6a6b863 Update NuGet packages 2015-09-24 17:55:38 +01:00
Antony Male 1731f2388a Change how ViewManager is configured
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.
2015-09-24 17:48:40 +01:00
Antony Male 7fe21eb40b Turn s:ViewModel into a proper binding, making it vaguely useful 2015-09-24 15:43:06 +01:00
Antony Male e8d9f95dfd Remove unnecessary usings 2015-09-24 13:37:29 +01:00
Antony Male 8548df498b Tidy up commented-out code 2015-09-24 13:36:58 +01:00
Antony Male c1c8a38dfb Merge branch 'feature/bindingproxy' into develop 2015-09-24 13:09:22 +01:00
Antony Male 240f013822 Improve documentation 2015-09-24 13:08:45 +01:00
Antony Male b378027018 Introduce proper testing 2015-09-24 13:02:54 +01:00
Antony Male 4d767f0364 Refactor to add {s:ViewModel}, and use that for actions 2015-09-24 12:12:37 +01:00
Antony Male 540482a5f4 YAY IT'S WORKING 2015-09-24 12:12:36 +01:00
Antony Male f4bf876c6b Mucking about with an integration test for BindingProxy
See also SetResourceReference and
BindingOperations.SetBinding(inputBinding, CommandProperty, new Binding("."))
2015-09-24 12:12:35 +01:00
Antony Male a703659095 Playing around with BindingProxy 2015-09-24 12:12:34 +01:00
Antony Male fc7f164c53 Remove unnecessary usings in unit tests 2015-09-23 21:46:36 +01:00
Antony Male a321c6f94a Start screens in Deactivated, not Initial
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.
2015-09-23 21:45:13 +01:00
Kai Eichinger 0089029ea8 Fixed broken tests for Systems that don't use "." as decimal separator 2015-09-22 20:53:56 +02:00
Antony Male 477d30ab4e Remove 'Task.Delay(1)' from unit tests 2015-09-22 09:18:42 +01:00
Antony Male 7f14d29696 Merge branch 'release/1.1.7' into develop 2015-09-09 12:48:49 +01:00
Antony Male 4114e1cf92 Bump version 2015-09-09 12:48:29 +01:00
Antony Male 3df0beaa23 Update changelog 2015-09-09 12:48:21 +01:00
Antony Male 44cff93967 Update NuGet packages 2015-09-09 12:43:31 +01:00
Antony Male 786438dc50 Fix unit test which could crash
We were trying to close a window on a non-STA thread after the test had
finished executing, which was evil.

Threading is hard.
2015-09-09 12:43:26 +01:00
Antony Male 0bf916691f Change my mind on whether Deactivated can be entered before Active
It was getting too convoluted: if something sets the state, the Screen should
enter that state
2015-09-09 12:27:21 +01:00
Antony Male fc1198dae6 Add version task 2015-09-08 22:10:11 +01:00
Antony Male a90f1d3c2f Add ruleset 2015-09-08 22:04:12 +01:00
Antony Male c1b842342b Add NUnit VS test runner NuGet package 2015-09-08 22:03:33 +01:00
Antony Male 11d91e7323 Fix brace style 2015-09-08 22:03:19 +01:00
Antony Male af5d2f0273 Do not allow Initial -> Deactivated transition
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.
2015-09-08 22:03:12 +01:00
Antony Male 6ef82a580b Allow ActionExtension to be instantiated with zero parameters 2015-09-08 13:56:27 +01:00
Antony Male 5c511603b6 Fix 'Eliminate ViewManager' 2015-06-12 19:47:28 +01:00
Antony Male 3b01fac260 Move to gitlink for symbols 2015-06-02 19:49:17 +01:00
Antony Male f58d0486c0 Make 'View' static 2015-06-02 16:02:18 +01:00
Antony Male 5e412af659 Behave better if s:View.Model used on a bad container
Fixes #6
2015-06-02 16:01:12 +01:00