[NumberBox] fix for text overlapping over spinbuttons #5985
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
StephenLPeters
added
area-NumberBox
|
some problems with Azure Pipelines, need to rerun |
The pipeline run failed due to failing tests:
Please, could you have a look and fix them if possible?:) |
You right, I did not realize that this project was used for automated tests. Will force push only actual fix for the problem, removing modifications to test project |
eugenegff
force-pushed
the
NumberBox-text-spinbuttons-overlapping-fix
branch
from
c22a6b1 to
fd18422
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Summary of TAEF Warnings: Summary of Errors Outside of Tests: Summary of Non-passing Tests: |
…dth is unrestricted (cherry picked from commit c22a6b1)
eugenegff
force-pushed
the
NumberBox-text-spinbuttons-overlapping-fix
branch
from
fd18422 to
d0a1cf0
Compare
done |
|
Issue, that is fixed by this PR
|
Could you please also attach the screenshot with the fix applied?:) |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
With fix, width unlimited, NumberBox grows as needed With limited width=140, text is clipped but does not overlap buttons |
@ranjeshj @StephenLPeters is it expected behavior? |
|
Probably, is there a proposed "better" behavior? |
|
I'm surprised it is clipping from the left, although I think this is the better behavior. I think this should likely be scrollable though. |
There are scroller inside, it remains scrolled to the position where it was scrolled to on focus lost event. On screenshot I just entered "123456789" text and caret was at the end. Usually for not just entered values it would be clipped from the right. Anyway, it is untweaked TextBox behavior, the same happens with NumberBox before this fix, as it clips text too, just at different point, somewhere between spin buttons. |
|
ah, so you can scroll this content to see the 12 that is being clipped in the screenshot? |
You need to focus on NumberBox to do this. But then, yes, by moving caret. OTOH, I have no HorizontalWheel on my mouse, but I still doubt that events from HWheel would be routed to unfocused control under the mouse pointer. Scrolled by focusing and moving caret: Default state, when value (12345678) is set from Model rather then being entered: But all of this is "bad path", where control is artificially constrained to inevitably clip content. The fixed bug was in "happy path" - when control is not constrained at all, but anyway overlapped text and buttons. |
|
"Happy path" (unconstrained NumberBox width) with fix "Happy path" (unconstrained NumberBox width) without fix |
|
Note also, that SpinButtonPlacementMode="Compact" has no such bug, only SpinButtonPlacementMode="Inline" |
In our app space is premium, so we slightly restyled NumberBox - among other we set NumberBox.InputBox.TextWrapping = TextWrapping::Wrap to remove "Clear all" button, but this had nice side effect for too large texts
That idea still requires non-overlapping TextBox and buttons, i.e. fix from current PR |
I do think this makes more sense to me at first glance, @SavoySchuler What do you think? @eugenegff could you open another issue detailing this as to not block this awesome change? |
|
@StephenLPeters , @beervoley can we speed up things a little bit? |
eugenegff
changed the title
Sorry about that! looks good. |
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
|
🎉 Handy links: |
|
🎉 Handy links: |
Fixes #5983