[SmartHint] Hint placement for "readonly" controls #3764
Merged
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.
Fixes #3762
Initially I thought this was just a fix for the
ComboBoxstyles, but it turns out that it was actually a common issue when the control is "readonly" (e.g.TextBox.IsReadOnly=trueorComboBox.IsEditable=False).While investigating the root cause, I stumpled upon 2 other issues that I fixed as well. So this PR covers:
Fixing a very weird issue in the
SmartHintdemo app page, where the initial calculation of hint would sit on top of the prefix text. I was not able to reproduce this outside of theSmartHintdemo app which puzzles me quite a bit. To "fix" it, I added a hack to the demo app, where it simply overrides the prefix/suffix texts in aLoadedevent handler on the demo app page itself; this seems to kick the calculation into gear. Another way to manually "fix" it is to simply clear the prefix text in the UI, and then set it to back to what it was (or anything non-emtpy basically).The Material Design 2 spec is quite clear in the visualization of a
ComboBoxin various states. We did not follow that completely since we did not float the hint once the drop-down was visible. A small change inSmartHint.csregardingHintHost.IsKeyboardFocusWithinfixes that issue. See the MD2 spec here (scroll down a small bit further to the "Behavior" section).Fixes the actual issue reported in the linked issue above. For "readonly" controls, we have a "business rule" that the prefix/suffix texts are always visible. For editable controls, the prefix/suffix visibility depends on the value of
TextFieldAssist.PrefixTextVisibilitywhich defaults toWhenFocusedOrNonEmpty. In the "readonly" case, the fact that the prefix/suffix is always visible was not accounted for, this PR changes that.Before
After
@corvinsz @Keboo Could you guys please check out this branch and give it a short spin? Try to play around with
Smart HintandFields line updemo pages, the former gives you a lot of control over how the hint/prefix/suffix and control behavior in general. It also showcases the different alignments, as well as all the controls supporting theSmartHintcontrol.And a small note-to-self: Think twice before undertaking a major refactoring of something as complex as the
SmartHintand the placement-hell that lies within...