Fixing an accessibility bug with the trackbar common control

re: Fixing an accessibility bug with the trackbar common control

nobugz — Wed, 11 Feb 2009 08:30:36 GMT

They *did* fix it, Minimum is at the bottom. But, they forgot about TBS_REVERSED. Will you tell them?

re: Fixing an accessibility bug with the trackbar common control

Larry Osterman [MSFT] — Fri, 30 Jan 2009 03:15:19 GMT

Actually I don't know why the .Net folks didn't fix this - their forms version of the common controls have a number of changes from the stock controls, I suspect they could have fixed it.

But they might have wanted to make it easier for unmanaged developers who were used to the control working in the unmanaged way.

re: Fixing an accessibility bug with the trackbar common control

Jiri Dvorak — Fri, 30 Jan 2009 02:52:18 GMT

Sorry I did not meant to offend you. I understand that there likely was reasonable reason for that decision at that time (btw. I did some checks after that post and the reversing is more complicated that I initially thought because of the ability to change the range at any time, even to invalid values). Just few days ago I tried to find trackbar reversing within the .NET framework. I did not found anything (not even equivalent of the TBS_REVERSED style). So this article hit me on sensitive spot, sorry.

re: Fixing an accessibility bug with the trackbar common control

Larry Osterman [MSFT] — Fri, 30 Jan 2009 01:24:13 GMT

Jiri, please let me know when you get your time machine working so I can go back to 1999 (that's when this field was introduced) and let the developers of the common controls know that they're making a mistake. They'll then be able to explain to me exactly why they didn't do it your way.

At this point it's a historical issue only. Sorry.

re: Fixing an accessibility bug with the trackbar common control

Jiri Dvorak — Fri, 30 Jan 2009 01:14:11 GMT

Why to do complex changes to internal implementation? I think that that having the control reversing the value when it is set and retrieved should be sufficient. Or I am missing something?

Also I do not think that this is the right kind of tradeoff to make. If done in the control, it would be implemented and verified once. Otherwise it is replicated in thousands of programs.

The additional thing is that having the flag do some "real" functionality would increase chance that it is really used. When it is only indication for the accessibility framework, chance that it will be properly set (or even used at all) decreases unless the developer really cares for accessibility of its program to check this.

re: Fixing an accessibility bug with the trackbar common control

Larry Osterman [MSFT] — Thu, 29 Jan 2009 19:34:36 GMT

Marcel, that might be the case. On the other hand, it's a tradeoff. It's not just "some locations" that would have to be updated in the control, I suspect the control has a lot of stuff that compares the current value with the max value to figure out positions and sizes. So you're trading off complexity in the control's implementation with ease of implementation on the part of the controls users. And the developers who write with the control are already used to this complexity.

re: Fixing an accessibility bug with the trackbar common control

Marcel — Thu, 29 Jan 2009 19:13:53 GMT

Of course I'm only suggesting that the new flag, which was introduced anyway, changes the semantics. Old stuff works as expected. New stuff has to set the flag anyway. And regarding the internal complexity, what's more to it than replacing "currPos" with (paraphrased) "(flags & TBS_REVERSED)? maxPos-currPos: currPos" at some locations? It's just what the programmer had to do outside of the control anyway put inside of it.

The only reason I can imagine why it was done this way: after the accessibility problem was found, the flag was added as a quick hack so that old code that already employs the "max-curr" trick did not have to be changed on the expense of a clean design.

re: Fixing an accessibility bug with the trackbar common control

Larry Osterman [MSFT] — Thu, 29 Jan 2009 17:55:22 GMT

Marcel: Changing the semantics of the control means breaking every single existing application that uses the control.

I'll take adding hint for the accessibility tools instead of breaking applications.

They could have made TBS_REVERSED change the semantics of the control, but if they did that it would dramatically increased the complexity of trackbar implementation (assuming that my guess about the implementation is correct). And that in turn would increase the chances of bugs in the trackbar.

re: Fixing an accessibility bug with the trackbar common control

Marcel — Thu, 29 Jan 2009 15:46:43 GMT

So, instead of creating a flag TBS_REVERSED that just switches the orientation internally in the control and be done with it once and for all, every programmer has to switch the direction manually outside of the control AND set a new special flag TBS_REVERSED that does nothing by itself, but is then in turn interpreted by a special case in the accesibility framework that then tries once more to immitate the additional calculations the programmer had to do.

That is... mind boggling one many levels.