Slightly OT - Wheel Scrolling Crashes VS2008 - Very Irritating!

[Jon Forrest]

This isn't actually a C# issue, but probably many people
who use C# have experienced the issue mentioned in
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=311797
where moving the scroll wheel, when the wheel is set to scroll
one screen at a time, causes VS2008 to crash.

This problem makes it very hard to use the C# IDE normally.

For a problem that is 100% reproducible, I'm surprised it's
taken Microsoft this long to produce a fix. It's also
surprising that something this obvious got past QA.

Anyway, I hope that anyone reading this who has any juice
inside Microsoft can do what they can to get this bug fixed.

Cordially,
--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
(e-mail address removed)

 

[Jeroen Mostert]

This isn't actually a C# issue, but probably many people
who use C# have experienced the issue mentioned in
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=311797

where moving the scroll wheel, when the wheel is set to scroll
one screen at a time, causes VS2008 to crash.

This problem makes it very hard to use the C# IDE normally.

For a problem that is 100% reproducible, I'm surprised it's
taken Microsoft this long to produce a fix.

The issue will not be whether it's 100% reproducible but what sort of impact
the bug has, versus the impact of developing and rolling out a fix (and mind
you, just because it's easy to reproduce does not necessarily make it easy
to fix). It's quite possible it's long fixed in the latest branch, actually,
but that still doesn't mean you can download a patch. Such are the drawbacks
of closed source.

This one is "very irritating" but not a showstopper (developers may be
mightily impaired by not being able to use the scroll wheel the way they
want to, but that doesn't count as showstopping). I'm guessing that unless
someone with clout is personally affected by it, this one is going to sit
things out all the way to SP1.

It's also surprising that something this obvious got past QA.

I'm surprised people are always convinced their bug is "so obvious" that the
testers had to be dunderheads for missing it. Don't forget that the benefit
of hindsight is incredibly big.

Exactly how inconceivable do you find it that changing the scroll wheel mode
from the default setting isn't part of standard QA procedures? Sure, now
that they *know* that it's a potential issue, they can make it part of
future procedures, but can you imagine what those procedures would look like
if you had to incorporate every possible permutation of Windows settings
right off the bat? It's plain undoable; compromises have to be made.

I'm willing to bet that the relative part of the user base that uses this
particular setting is just *small*. Small enough not to get noticed during
testing, large enough to get noticed when the RTM hits the masses. It
doesn't really matter how obvious it is if there's not enough chance to
notice the problem.

I'm not saying that your problem is trivial or ignorable, mind you -- just
that it's completely conceivable that it got past QA, and that it doesn't
actually say anything about the Q of QA. There will always be stupid bugs
that just plain manage to slip under the radar, no matter how many betas and
CTPs and in-house tests you throw at things. Look at the bright side: it's
highly unlikely that any future version of VS will have a similar bug.

 

[Jon Forrest]

I'm not saying that your problem is trivial or ignorable, mind you --
just that it's completely conceivable that it got past QA, and that it
doesn't actually say anything about the Q of QA. There will always be
stupid bugs that just plain manage to slip under the radar, no matter
how many betas and CTPs and in-house tests you throw at things. Look at
the bright side: it's highly unlikely that any future version of VS will
have a similar bug.

If it weren't for the fact that wheel scrolling has worked
perfectly for every release of Visual Studio I know of up
to now, I'd be more sympathetic. Regressions are a different
class of bug than problems with new features.

--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
(e-mail address removed)

 

[Jeroen Mostert]

If it weren't for the fact that wheel scrolling has worked
perfectly for every release of Visual Studio I know of up
to now, I'd be more sympathetic. Regressions are a different
class of bug than problems with new features.

Developers and QA were likely were never aware of potential problems with
different scroll wheel settings. You'd have a point if they had explicitly
tested and supported the different wheel settings for every release, and had
somehow neglected to do this for VS 2008. That's possible, but not very
likely. The feature was probably never expanded beyond "wheel scrolling",
and "screen at a time scrolling" never treated as a subfeature subject to
regression (which is reasonable, since it's actually hard to imagine what
disaster has befallen the new code that it can't handle it). A regression as
far as the user is concerned, but a hard to catch new bug for the
developers, and a missing scenario for QA.

To look at it another way, if screen-at-a-time scrolling had *never* worked
properly in any release so far, I sincerely doubt you'd be "more
sympathetic" -- you'd probably rail against it still not supporting
something this basic for so long, and you'd have a good point at that. Now
that it's broken, though, the VS developers and QA will be aware that it is
a breakable feature and not something that just happens to work all the
time, if they weren't aware before.

Obvious? Yes. Annoying? Yes. Stupid bug? Undoubtedly. A demonstration of
laughably bad QA? I don't think so. It's impossible to tell in any case
without hard data, and my argument is that the failure to catch this bug,
while glaring to those affected by it, is in itself too marginal to base
conclusions on.