#AUTO HIDE SCROLLBAR WINDOWS 10 HOW TO#
The following example shows how to use the ScrollBarVisibility enumeration members to set the HorizontalScrollBarVisibility property of a ScrollViewer control. The dimension of the content is not affected by the dimension of the ScrollViewer. Scrolling is still enabled, and can occur through touch, keyboard, or mouse wheel interaction. Scrolling is disabled.Ī ScrollBar does not appear even when the viewport cannot display all of the content. For a vertical ScrollBar, the height of the content is set to the ViewportHeight of the ScrollViewer.Ī ScrollBar does not appear even when the viewport cannot display all of the content. For a horizontal ScrollBar, the width of the content is set to the ViewportWidth of the ScrollViewer. The dimension of the content is set to the corresponding dimension of the ScrollViewer parent. In fact, if we were able to get it figured out _here_, we'd probably be able to ingest the changes upstream in (introduced in v1.0)Ī ScrollBar appears only when the viewport cannot display all of the content. It would probably be really easy to just have two control classes, and just instantiate one or the other. I'd think the hardest part would be supporting both the current behavior and the requested behavior in _one_ control class. So I actually don't think that the changes that were outlined above would be terribly difficult to implement. This is at least in the near term - sure, the platform fix would be better for the ecosystem, but if you want a fix _now_ for the terminal, doing it here is going to get you the fastest results.įortunately, quite a bit has changed since November, and we've got quite a bit more XAML in our project than we used to. We'd definitely be willing to back up a request, though knowing what I know about their resourcing currently, it'd almost certainly be easier for us to add a custom templated scrollbar than for them to add the behavior we're looking for to the platform. As of late 2019, the TerminalControl project has XAML resources as well, so adding the appropriate XAML files shouldn't be that big of a Probably the best place to push for that would be filing an issue over in the WinUI repo. This will be substantially easier to do nowadays. Not _impossible_, but certainly not easy.Īs another fun challenge, the TerminalControl project doesn't currently have _any_ XAML files or resources, so we'd need to add those, or find a way to define them in TerminalApp and have them used by TermControl. So we'll need to basically make a custom scrollbar template for the TermControl scrollbars. Unfortunately as far as I am aware, there is no easy way to force the scroll bar to remain in its expanded state for your app, if that is desired I think your only option would be to retemplate your scrollbar control and edit the VisualStates for the ConsciousStates group so that the Collapsed and CollapsedWithoutAnimation are eqivalent to the expanded states and to remove the Expanded to Collapsed transition. On older versions of the OS MouseIndicator and TouchIndicator behave quite differently, essentially how mike described it.
#AUTO HIDE SCROLLBAR WINDOWS 10 WINDOWS#
The only difference is that when conscious scroll bars are disabled by windows system setting, scrollbars in the touch indicator state are not hit test visible, meaning you cannot drag the thumb to scroll. On windows versions where conscious scroll bars are available (RS3+) the TouchIndicator state is nearly equivalent to the mouse indicator state. If someone with more XAML experience would be willing to help us with this one, that'd be much appreciated.įrom a internal mail thread back in April: Right now we support "visible" and "hidden", but we want an "always" state added.
| "hidden" | The scrollbar is always hidden |
| "visible" (default) | The scrollbar "reveals" on mouseover, as it does currently. | "always" | The scrollbar is always visible, like conhost.exe | To clarify: this proposal is to have the scrollbar have three visibility states: Actually getting the XAML scrollbar to behave that way was a lot tricker than we had originally hoped, but maybe we can still get this in. You know, I really want the scrollbar to have these options too.
0 kommentar(er)
