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; }
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.
Thanks very much! What I mean was that if I look at the obsolete methods/properties under 20.2 docs I would expect as big [OBSOLETE] banner
Ah, I see. I'm not quite sure how that gets done in the docs. But I sent an e-mail off to our docs department and asked them to look into it and see if we can get something into the help to indicate that the old property is obsolete.