Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
205
GetVerticalScrollBarWidthResolved Obsolete - Fix unclear in documentation
posted

Upgrading from V18 to V20 we see this warning:

warning CS0618: 'ScrollBarLook.VerticalScrollBarWidthResolved' is obsolete: 'This property is obsolete and does not account for Dpi Scaling on multiple monitors. Use the GetVerticalScrollBarWidthResolved method that takes in a control.'

It is clear that we need to be using GetVerticalScrollBarWidthResolved and pass in a control

This is documented here: https://ko.infragistics.com/help/winforms/20.2/infragistics.win~infragistics.win.ultrawinscrollbar.scrollbarlook~getverticalscrollbarwidthresolved(control)

I am unclear which control is required here as we are running this on an UltraTree already

Also if I look at the other methods/properties in the documentation I would expect to see that they are now obsolete with an example fix

Here is a code fragment from where the warning is generated:

                UltraTree ultraTree = SelectedTab.LinkedTree();

                int horizontalTreePadding = 12;
                int ultraTreeWidth = this.Width - horizontalTreePadding;
                int elementIssueWidth = ultraTreeWidth;
                int elementIssueHeight = 30;
                int buttonBoundaryPadding = 90;
                int topBoundaryButtonPanel = (this.Height - buttonPanel.Top) + buttonBoundaryPadding;
                int ultraTreeHeight = ultraTabControl.Height - topBoundaryButtonPanel;

                if ((ultraTree.Nodes.Count * elementIssueHeight) > ultraTree.Height)
                {
                    elementIssueWidth -= ultraTree.ScrollBarLook.VerticalScrollBarWidthResolved;
                }

Parents
  • 469350
    Verified Answer
    Offline posted

    Hi Sam, 

    As far as the VerticalScrollBarWidthResolved method goes, you need to pass in whatever control contains the scrollbar. In this case, that would be the ultraTree. It might seem a little weird, since you are accessing the method on a sub-object of the tree itself. But ScrollBarLook is a common object defined in the Win assembly that is used by a whole bunch of controls, and as it happens, it does not have a reference back to the control that owns it. So you have to call the GetVerticalScrollBarWidthResolved method and pass in the control yourself in order to get an accurate measurement. 

    It's also worth noting that if you are running your application on a system with multiple monitors running at different DPI, then the width of the scrollbar (and in fact any system metrics) can change while the app is running. But this will only happen if your application opts in to high DPI support. 

    Sam Mackrill said:
    Also if I look at the other methods/properties in the documentation I would expect to see that they are now obsolete with an example fix

    I'm not exactly sure what you mean by this. I think what you might be asking here is... why don't you have to call a similar method for other metrics, like the size of other elements like buttons and such.. Is that your question? If so, then the answer is that those other elements are inherent to the tree and/or have a reference back to the control that owns them. Thus, they can return the correct sizes because they already know which control to use.

    The key here is that ScrollbarLook does not have a direct reference back to the owning control. 

Reply Children