Changes
* Add the "DynSL" instance to the infrastructure list of your ACM context.
== Goal 2: Create items for the Dynamic Selective List ==
{{Hint|The dependency object specifying the value influencing the selectable items must be either the target object (the one with the DynSL property), or anywhere above it in the hierarchy.}}
== Goal 5: Add a criterion to connect the dots ==
{{Hint|Dependency objects are looked up in the parent hierarchy of the object with the DynSL property. The closest "ancestor" with the correct class and a matching property is chosen as dependency object (and its matching property as dependency property). If an object has multiple parents, there can be multiple closest matching dependency objects - this can lead to a larger amount of selectable items, because the results for all dependency objects are accumulated. }}
== Releasing the ACM meta definitions ==
You can configure Dynamic Selective Lists to allow much more complex scenarios. For example, you can remove the restriction for the dependency class on the criterion. You can define the target object as the dependency object, too, so it depends on a different property of itself. You can even specify multiple criteria, potentially with different dependency objects. It is also possible to define multiple properties with dynamic selective lists depending on each other successively.
== Known issue workaround: Not ignoring NULL criteria doesn't work ==
One of the features of DynSL is to specify a criterion with the dependency value NULL that should only yield items with the criterion property value NULL (instead of just yielding every result). This can be achieved by setting the criterion's "IGNORE_NULL" property to False and the dependency property value to NULL.
Or rather, it should be achieved that way; there is a bug on the WinX client in version 4, which basically always ignores null values no matter the criterion configuration. Fortunately, there's a workaround:
If you override the dependency property in customizing programmatically, so it always returns any value definitely never occurring "in the wild" instead of NULL, and do the same for the item's criterion property, you achieve the desired result. We're working on fixing the bug, but in the meantime this should help you work around it.
<source lang = "csharp">
// do this for both the dependency property as well as the item's criterion property
var val = base.MY_PROPERTY;
return val ?? "NULL"; // this is the same as as saying, 'if the value is not null, use it, else, use whatever I wrote after the "??" operator'
</source>
Why does this work? Currently, the client handles NULL values differently than regular values (ignoring them, basically). However, with the above code you're changing a NULL into a regular value, so there's no extra behavior.
<!-- = Studio = -->
