You are here:About>Computing & Technology>Visual Basic> Using VB.NET> Bug Reporting to Microsoft - A Continuing Story
About.comVisual Basic
Newsletters & RSSEmail to a friendSubmit to Digg

Bug Reporting to Microsoft - A Continuing Story

From Dan Mabbutt,
Your Guide to Visual Basic.
FREE Newsletter. Sign Up Now!
Oct 9 2007

Ever find a "reportable" bug in a Microsoft Product?

It's not a huge bug. In fact, it was only mildly irritating once I confirmed for myself that it really was a bug. But it seemed so clearcut ... so definite ... so undeniable. There are lots of things that I might like to see improved or changed in VB.NET, but I had never really come across such an obvious and reproduceable bug before.

The other thing is that I was hard at work on a new article and this bug totally threw my schedule off course. (The article is all about how to do custom controls using VB.NET. Look for it soon.) At first, I thought I was doing something wrong. Then I thought that there was some obscure behavior that I didn't know about. Then I spent more time than I should running tests to be as certain as I could that it really was a bug.

(True confessions: As I write this, I still have this horrible worry that I've done something completely obvious, stupid, and wrong.)

But after doing all this checking, I had no chance whatsoever of meeting both the deadline and my own standards for quality with the article. So I decided to write about the experience of submitting a bug to Microsoft -- and the bug itself. You may want to submit one of your own. But there's another benefit I discovered that you might also want to take advantage of and I'll get to that a bit later in this article.

First, the bug.

Reproducing this bug is not completely obvious. But here are the steps:

  • Create a standard Windows Application in Visual Studio 2005
  • Add a ListBox to the form
  • Set the DrawMode of the ListBox to OwnerDrawFixed
  • Add this code to the Form1.Load event:

Debug.Print("ListBox1.DrawMode: " _
   & ListBox1.DrawMode.ToString)
Debug.Print("ListBox1.Height: " _
   & CStr(ListBox1.Height))
ListBox1.ItemHeight = _
   CInt(ListBox1.Height / 3)

  • Place a breakpoint on the last statement so execution stops just before it's executed.

Run the program. Everything is fine at this point. If you display the value of ListBox1.Height in a ToolTip by selecting it with your mouse, you get the same value displayed in the Immediate Window. Now single-step the execution once to run the next statement. Note that this statement uses ListBox1.Height in a calculation. In all my tests, this incorrectly changes the ToolTip report of the value of ListBox1.Height. See my illustration below:

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

This seems like a pretty clear bug to me. It appears that involving the property in a calculation changes the reported value in the ToolTip. Confusing, but not deadly.

If you discover a bug like this, Microsoft encourages you to report it at their Feedback site:

https://connect.microsoft.com/feedback/Search.aspx?SiteID=210

It takes a little while to do this because they collect a lot of information from you before you even get to the "bug reporting" part of the process. That's probably for the best. It probably keeps nuisance reports a bit lower than they would be ordinarily.

One of the things that they ask you to do is check the existing bug reports to see if someone has already reported the one you found. There's a handy search to help you do that. If you find that someone else has already reported the bug, you can "vote" on how serious you think it is.

This may actually be one of the best reasons for going through the process of answering all their questions to get to this point.

As it turns out, there are a lot of reported bugs. I searched for the keyword "height" and found that there were over 250 reported bugs containing just that term. I thought that was quite a lot. Some were clearly not bugs. For example, one of the reported "bugs" was "Visual Studio 2005 Design Editor is Terrible". Maybe that's a valid criticism (but I don't agree with it - I think it's pretty good). But it's not a "bug". Most, however, really were fairly obscure bugs similar to the one I reported.

If you're confused by something that VB.NET is doing, you might want to search the bug database and see if it's just you or if it really is a bug!

One of the reasons I thought this might be of more general interest is that I have a terrible time actually communicating with a real person at Microsoft. You might have the same experience. I talk to the "technical evangelists" at seminars and get their business cards, but nothing ever happens. You might think that content control of a major web site like About Visual Basic would merit a bit more attention (it certainly does with other software vendors and publishers) but you would be wrong. The thought occured to me that this is an opportunity to find out just how thick the wall around Microsoft actually is. I'll update this article and keep you informed about just what happens to the bug. If you would like to check for yourself, the ID for the bug is 303125. Use the "Advanced Search" to find it using the ID.

On the next page, you'll find the continuing story of what happened to this bug!

 All Topics | Email Article | | |
Advertising Info | News & Events | Work at About | SiteMap | Reprints | HelpOur Story | Be a Guide
User Agreement | Ethics Policy | Patent Info. | Privacy Policy©2008 About, Inc., A part of The New York Times Company. All rights reserved.