| Age | Commit message (Collapse) | Author |
|---|
|
This adds support for creating new variants and having them show up in
the property list. Still todo:
- AsyncWork guard more of PropertiesVM + add tests
- Error display for failing to create a variant
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This should ensure that exceptions thrown inside async void
methods do get rethrown as part of the Teardown of a given test.
This removes the eventhandlers on AppDomain.UnhandledException
and also removes the second SyncContext implementation which
did not capture/propagate the exceptions.
|
|
|
|
As long as it signals when something potentially changed, that's good
enough. Any consuming code should still operate correctly if it signals
a change when there wasn't one, it's just a perf it. We can revisit if
the perf hit ever becomes noticeable.
|
|
|
|
|
|
|
|
|
|
The placement of this is important. Since the value type is likely an
enum, it's not going to have an out of bounds default() value. So,
despite only setting the ValueDescriptor, Value will still look like a
valid value, so ValueDescriptor takes presedence.
|
|
|
|
Basic autocomplete support
|
|
|
|
This is the most basic version of this to support the status quo for
Android. The hard part is really the UI, so this will get us a
significant part of the way towards a more robust version.
|
|
Fixes #294
|
|
Also fixes Add not having a restriction.
Fixes #367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weirdly enough, WPF doesn't support the group notices that it
introduced. Fixes #340
|
|
|
|
Bindings editor
|
|
Add source descriptor and rebase object VM
|
|
|
|
|
|
We don't actually need the complicated version of this that seemed
flawed. We just need to provide a context and execute the calls. We may
need to make this more like the original later, but we're generally not
executing things off-thread within our VMs.
|
|
|
|
|
|
|
|
|
|
|
|
This re-fixes null editors from the last commit, but also fixes nulls
past the first one.
|
|
This moves away from a straight name on the IObjectEditor to a ITypeInfo
describing the type. As this is currently expect to be non-null, it was
added to the tests (as well as some missing .Target assignments).
Caught up in this change were some tests being moved down a rank from
PanelViewModelTests to PropertiesViewModelTests.
|
|
|
|
|
|
|
|
We don't really need this to be separate, it only helped to diverge
capabilities that arrived in the base value view model but not in the
object one. While it might be a little weird to have Value available for
something that is meant to be edited at a sub-property level, it
wouldn't be the first VM that has a separate "real" value property and
we actually do need a PVM<object> that we can set the value on for
bindings.
This also moves the assignable types request to be fired only when
actually requested.
|
|
ValueDescriptor ended up being used for overlapping purposes:
binding/resources for the source but then for some values like objects
and predfined values it had extra information not contained in the
Value. SourceDescriptor was added to hold things like bindings or
resources that describe where the value came from, while ValueDescriptor
will continue to hold extra details about the value.
There were two possible approaches to this, to add the object property
as-is in this commit, or to add bespoke properties for a Resource and
Binding. Ultimately both approaches have fairly similar level pros and
cons. What it ended up coming down to for me is that these properties
are mutually exclusive. While we can guard against this in a few ways
(target the same backing property, throw an exception), both of these
cases require extra code to be mindful of in some usage where it does
not with a single property, or worse it is silently unexpected behavior.
While it is cleaner to not have to cast, the risk of introducing extra
code complexity for the sake of structure tips the scales.
|
|
|
