Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NumberBox: Visual updates #5032

Merged
merged 4 commits into from
May 21, 2021
Merged

NumberBox: Visual updates #5032

merged 4 commits into from
May 21, 2021

Conversation

teaP
Copy link
Contributor

@teaP teaP commented May 17, 2021

The main change here is that the inline spin buttons are hovering above the inner TextBox, so that the TextBox border extends around the entire control. The good news is that corners are now no big deal and we can remove corner-specific code. The bad news is that when the spin buttons are disabled (a likely scenario at least part of the time) we don't want the TextBox taking hover as input, so I created an InputEater button in the template which solves the problem. (I don't love that it's a button; if you have alternate suggestions I'm all ears.)

@ghost ghost added the needs-triage Issue needs to be triaged by the area owners label May 17, 2021
@mdtauk
Copy link
Contributor

mdtauk commented May 17, 2021

Could you please provide screenshots of the changes.

@mdtauk
Copy link
Contributor

mdtauk commented May 17, 2021

Also, here is a quick thought on how Number Box could handle its buttons

image
There is treating the buttons like the Search Button and Clear Buttons - contained within the TextBox, with smaller backplate visual but still 32 x 32 hit target.

Then there are the buttons with visual separators, where the backplates would probably be full height.

@beervoley beervoley added area-NumberBox NumberBox Control team-Controls Issue for the Controls team area-UIDesign UI Design, styling labels May 17, 2021
@StephenLPeters StephenLPeters removed the needs-triage Issue needs to be triaged by the area owners label May 17, 2021
Comment on lines +627 to +635
auto state = L"SpinButtonsCollapsed";

if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Inline)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsVisible", false);
state = L"SpinButtonsVisible";
}
else if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Compact)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsPopup", false);
state = L"SpinButtonsPopup";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use const expr's for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never have before, so 🤷

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh interesting, in other controls, we do that all the time🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - that's up to you. We typically define the state names in the .h file, like
static constexpr std::wstring_view s_scrollBarsSeparatorExpanded{ L"ScrollBarsSeparatorExpanded"sv };

dev/NumberBox/NumberBox.xaml Show resolved Hide resolved
dev/NumberBox/NumberBox.xaml Show resolved Hide resolved

<VisualStateGroup x:Name="SpinButtonStates">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Add empty line here :)

Comment on lines +627 to 636
auto state = L"SpinButtonsCollapsed";

if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Inline)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsVisible", false);
state = L"SpinButtonsVisible";
}
else if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Compact)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsPopup", false);
state = L"SpinButtonsPopup";
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could convert this to a lambda and have a constant string, but not sure if that adds more value. @teaP @StephenLPeters thoughts?

Copy link
Collaborator

@marcelwgn marcelwgn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it expected that I can't reach the inline increase/decrease buttons with keyboard anymore? It jumps to the input eater, however I can't actually use the increase/decrease buttons. Clicking on them works though.

@@ -165,25 +238,40 @@
</Grid>
</Popup>

<Button x:Name="InputEater"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you hover over the inline buttons and slowly move to the left, at some point this will eat the hover input and it seems that nothing is receiving the hover. Do we need to size this better?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a 4px border around the buttons, so there is an area where nothing is getting hover between the buttons, but I can trim it on the left side so that there's no dead space there.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are aso small regions above, below, to the right and between those buttons that have the same effect. We hardly can fix the issue with the area between the split buttons without having two buttons right? I think it is fine right now.

@ranjeshj ranjeshj requested a review from RBrid May 19, 2021 13:30
@teaP
Copy link
Contributor Author

teaP commented May 19, 2021

Is it expected that I can't reach the inline increase/decrease buttons with keyboard anymore? It jumps to the input eater, however I can't actually use the increase/decrease buttons. Clicking on them works though.

Oops, good catch! I'll fix that. The up/down buttons are not supposed to get keyboard focus either (since you can just use the arrow keys inside numberbox).

Copy link
Collaborator

@marcelwgn marcelwgn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. For @mdtauk, here the screenshots:

Screenshot of NumberBox in dark theme with inline buttons

Screenshot of NumberBox in light theme with inline buttons

Bit surprised that disabled buttons don't receive focus, the workaround with the input eater seems reasonable here even if it's not the fanciest one.

@@ -165,25 +238,40 @@
</Grid>
</Popup>

<Button x:Name="InputEater"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are aso small regions above, below, to the right and between those buttons that have the same effect. We hardly can fix the issue with the area between the split buttons without having two buttons right? I think it is fine right now.

@mdtauk
Copy link
Contributor

mdtauk commented May 19, 2021

Looks good to me. For @mdtauk, here the screenshots:

Screenshot of NumberBox in dark theme with inline buttons

Screenshot of NumberBox in light theme with inline buttons

Bit surprised that disabled buttons don't receive focus, the workaround with the input eater seems reasonable here even if it's not the fanciest one.

Thanks, I wasn't sure if the borders were to be retained or not. Are the hover and pressed backplates full height, or rounded with padding, like the clear and search buttons.

Oh also, shouldn't those chevrons be updated to the FluentUI System Icons

@teaP
Copy link
Contributor Author

teaP commented May 20, 2021

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Comment on lines +627 to +635
auto state = L"SpinButtonsCollapsed";

if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Inline)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsVisible", false);
state = L"SpinButtonsVisible";
}
else if (spinButtonMode == winrt::NumberBoxSpinButtonPlacementMode::Compact)
{
winrt::VisualStateManager::GoToState(*this, L"SpinButtonsPopup", false);
state = L"SpinButtonsPopup";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - that's up to you. We typically define the state names in the .h file, like
static constexpr std::wstring_view s_scrollBarsSeparatorExpanded{ L"ScrollBarsSeparatorExpanded"sv };


<VisualStateGroup x:Name="SpinButtonStates">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should that be 'SpinButtonsStates' since you use 'SpinButtonsXXX' for the states?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one plural is probably enough?

…don't need to worry about which elements have corners anymore.
@teaP
Copy link
Contributor Author

teaP commented May 21, 2021

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@teaP teaP merged commit a43a2ab into main May 21, 2021
@teaP teaP deleted the user/teaP/NumberBox branch May 21, 2021 06:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-NumberBox NumberBox Control area-UIDesign UI Design, styling team-Controls Issue for the Controls team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants