Validate all width/height properties of Layoutable when they are set #15753
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
You can test this PR using the following package version. |
TomEdwardsEnscape
force-pushed
the
fixes/validate-layoutable-dimensions
branch
from
5c9f8ae
to
1fcf803
Compare
|
You can test this PR using the following package version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is currently possible to set the
Width,Heightand associated min/max properties ofLayoutableto values which result in aInvalidOperationExceptionwhenMeasureis called.If the control is visible, then changing the properties will immediately trigger a new measure and the exception above will be thrown. But if the control is not visible, then the exception will not be thrown until later on, and the point at which the invalid value was set will not be known.
This behaviour makes validation and debugging harder. Users of Avalonia must validate the values they set manually, which means duplicating logic from inside Avalonia's private methods.
What is the updated/expected behavior with this PR?
The relevant properties now have validation methods which immediately block invalid values, no matter what state the control is in.
An exception will be thrown when an invalid value is set. This allows immediate error handling with a try/catch block.
The exception message will be something like
-10 is not a valid value for 'Width', which is considerably more useful thanInvalid size returned for Measure, which is the message of the exception that would otherwise be thrown byMeasure.Breaking changes
It's possible that a custom control somewhere supports values that the validation methods in this PR reject. This can happen if its overridden
MeasureOverridemethod continues to return a valid size.This weird situation could be worked around by providing new properties on the custom control which don't block negative or infinite values.
Obsoletions / Deprecations
None