They broke the scroll control!
Microsoft's Maximum is just a little less ...
While working on the next segment of the tutorial about GDI+ I discovered another change between VB 6 and VB.NET.
... but this time, change is not good!
The example in the next GDI+ segment includes a scroll bar control. The result of scrolling had to be a decimal number between 0 and 1 so I added this code to the Scroll event:
myDecimalVar = BlendScroll.Value / 100
But the highest value I could get was .91!!!
A little experimentation followed by a little research yielded two conclusions:
- Yep! That's right. That's the way it actually works.
- I'm not the first to discover this. I was actually relieved to find a few other people have come to the same conclusion.
VB 6 didn't work this way! If Maximum was set to 100, that's what the Value property was when the control was scrolled to Maximum.
And Microsoft confirms it! The documentation of the Maximum property at MSDN has this to say about it.
"The value of a scroll bar cannot reach its maximum value through user interaction at run time. The maximum value that can be reached is equal to 1 plus the Maximum property value minus the LargeChange property value. The maximum value can only be reached programmatically."
So if Maximum is 100 and LargeChange is 10 (the default values), then the "real" maximum is 91!
Why did Microsoft do this!!??That's one thing I did not find in my research! Does anyone have a clue?
Comments
Obviously I don’t know, but my guess is that they’re treating the “large change” as the height of a window, and the value of the scroll bar is now consistently determined as being the top edge of this window.
Ummmmm …..
I don’t think that’s it. “Large change” can be set to any positive integer so it wouldn’t necessarily correspond to anything like that.
Actually, I did read one un-authenticated explanation. The explanation was that if this prevented an error when “large change” was added to the current setting and made it exceed the actual maximum.
But that sounds flakey to me too. How much trouble would it be for a little code in the component to test for and prevent that problem?
To impress Jodie Foster, the same reasont hey let a bunch of C programming geeks destroy VB in the first place.
I think it has to do with the width of the control handle. Change the large size to 20 and you will see the width of the handle is twice as large.
Now where do you put the value? at the start of the handle, at the center of the handl or at the end of the handle?
MS probably took the easy way out and used the left edge of the handle which leaves the length of the handle short.
If there really was a chance of impressing Jodie Foster, it might be worth it.
But, even though I moan and groan about some of the things that they have done too, I’m not going to agree that VB has been “destroyed”. VB.NET is a pretty wonderful development environment. There are these “issues” that pop up every now and then, but they are vastly overweighed by the huge advance.
About the width of the thumb, however. Nahhhh … don’t see that as a justifying reason.
You can (and since you now have to write your own code to make up for this problem — you MUST) write code to determine when the maximum has been reached using the value of the LargeChange. Microsoft could have embedded this code into the control so we didn’t have to do this.
I’ll agree with one thing, however, they DID seem to take the easy way out.
It’s microsoft being lazy, you could always implement Mx+b to make up for it.
It’s called an error, a mistake, a boo-boo, a flaw, a wart, a bugaboo, an undocumented feature — a bug. Hey, even God made gnats and celery, I think I can forgive this. Just so’s it gets fixed in a future release.
Yeah, it’s the width/height of the thumb. To reach the minimum value the point for reading a value must be the left/top of the thumb. When they get to the right/bottom they either have to switch the value “read” position or continue to read from the left/top edge of the thumb.
Now they could have corrected this by having the value “read” position move from the left to the right edge as the thumb traverses the control, but that is just plain wrong and we all know it. The real problem is this control should never be used for anything other than a basic scrollbar. It was really never designed for tracking value changes.
For what you are trying to do you should be using the correct control, which is the Trackbar, which allows the thumb to move past the edge of the “groove” on which it travels.
Take a look in:
http://www.codeproject.com/KB/miscctrl/understandingScrollbars.aspx
Understand .NET Scrollbars
By Marc Clifton
Hope this help!
Thanks for the reference. Marc’s article does explain large change and small change … but it fails to even mention the inaccuracy that is the subject of most of this thread.
I got the same problem in C#, its not exclusive to VB.
Thanks for the additional information. I haven’t experimented there so I didn’t know for certain. That points back to .NET rather than the language shell.