I had all of the trouble in the world with getting the very bottom of the canvas to display. The scroll bar did not seem to be working correctly. Since there was a little maths to work out the max value, large increment and the panel's top property I figured that the problem lay there.
It was only after a bit of debugging that I found that the scroll bar was incapable of reaching its maximum value of 100. It would stop at 91 irrespective of whether it would be moved through a small change, large change, or manual drag.
A search of Google later revealed that the maximum value of a scroll bar is at most MaximumValue - (LargeChange + 1) as quoted from http://msdn.microsoft.com/smartclient/understanding/netcf/FAQ/default.aspx#5.40
This is actually incorrect. It is Maximum - LargeChange + 1 (the brackets stuff it up)
I checked it on WinForms and the same. There is even a passing note about it in the help: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformsscrollbarclassmaximumtopic.asp
There is not much chatter on the web about this problem so I figure it should be fleshed out a bit.
I checked in VB6 and this problem does not occur.
What a stuff up!
Two things:
1. This is going to be with us for the entire life of .Net.
Today I wrote code recognises this problem and takes it into account when calculating the 'real' maximum. If it were ever to be fixed in the framework then my program will no longer function correctly. Microsoft will never be able to fix it since if they do then software will break.
(I guess the could release a new scrollbar called ScrollBarEx while keeping the old one around for compatibility.)
2. Finding information about this was a little difficult. There is a note in the Maximum property field of the ScrollBar help. No mention the Value property and no mention in the ScrollBar class. In fact it only says:
To adjust the value range of the scroll bar control, set the Minimum and Maximum properties.
This is a bit misleading especially if you set the LargeChange to be the same as Maximum. The maximum value ever reached will be 1.
While I am at it, they were smart enough to recognise that the LargeChange could not exceed Maximum when in design mode and the LargeChange gets reset back to Maximum if it is exceeded - well you would think so. They stuffed this up too. The LargeChange value is reset back to Maximum + 1.
I have just finished reading the Framework Design Guidelines. I will post about this later. The refreshing aspect of this book is that Microsoft insiders add their comments and admit to mistakes that were made. This was great. When programming against those areas of the framework that contain these problems, rather then being frustrated I find myself being accepting of the issues in the knowledge that the designers themselves know that they could have done a better job - reading and writing a simple text file for example.
I think that this should be extended to the Help. Along with sections of Thread Safety, Remarks, Examples, Requirements and See Also there should be another section called "Narration" or "Background information" or "Editorial". This section would allow frank comments to be added by the Microsoft Team to express why things were done the way they were done, the history, the mistakes that were made, what influenced their design decisions, how to best use the class or property, etc.
This would be a very disarming and I think would provide for a much better help system.
In the example of the scrollbar I would except that they would say:
Editorial
We had the work experience student in that week so we gave them the scrollbar to write - how could they possibly stuff it up. We apologise.
:) That was a bit harsh.
No comments:
Post a Comment