Visual Basic

  1. Home
  2. Computing & Technology
  3. Visual Basic

Bug Reporting to Microsoft - A Continuing Story

Updates!

By Dan Mabbutt, About.com

Oct 9 2007

Update - 8 October 2007

I just received what seems to me to be a computer generated response. Something that gives it away is that it was signed by "the Microsoft Connect Team". Although a real person is mentioned in the message, I don't have any way to actually contact that person. It's one of the techniques that companies use these days to keep you at arm's length so people working at the company can focus on stuff that makes a profit right away instead of wasting time communicating with customers.

The text of the message is ...

"Hi! Thanks again for reporting this issue. We are very close to the end of this product cycle and need to act faster on issues. We haven't been able to reproduce this problem so I'm resolving it as 'no repro'. Please reactivate this issue if you can provide more detailed repro steps so we can reproduce the problem. thanks, Miguel A. Lacouture [Windows Forms team]."

The graphics I included seem to me to be a pretty clear indication that the problem really does exist. I plan to "appeal" their brushoff, but before I do, I'm wondering if any of you can reproduce the problem. The goal is to be able to say, "Maybe you can't reproduce it, but all these people can." Let me know. (There is a way of actually contacting me. I get behind on my email, but I do try.)

Update - 9 October 2007

You can't fault Microsoft for simply ignoring things. I received a notification that the status of the problem was changed back to "Active". The detail at their site also states that they were still unable to duplicate the bug, and they gave me seven days to provide more information.

In the meantime, a couple of great About Visual Basic readers did provide some additional information. Larry Zipper said he was able to easily reproduce the bug! Thanks Larry!

Paul Marshall peeled back the problem even more. He also said he was able to duplicate the bug when ListBox.IntegralHeight is set to True but not with it set to False. Checking the documentation for ListBox.IntegralHeight, I discover that it "Gets or sets a value indicating whether the control should resize to avoid showing partial items."

That does seem to be "involved" in the bug. Testing shows that the Height property doesn't change until this statement is executed:

ListBox1.ItemHeight = CInt(ListBox1.Height / 3)

So when ItemHeight is adjusted, Height is too. That's certainly not obvious behavior (and probably should be mentioned in the documentation) but it does seem to explain what's happening.

Darn! And I was sure I had a live one!

All in all, I give About Visual Basic readers Larry and especially Paul an A+ for their timely help. I give Microsoft a B. They did respond quickly and they did actually look at the information submitted. (But they did so in their typical arms-length and impersonal manner.) They didn't check out the bug any deeper than a coat of paint.

It's been a fun process. I'll update the report at Microsoft and admit now that (as Microsoft famously has said), "That's a feature, not a bug!"

Explore Visual Basic

By Category

About.com Special Features

Visual Basic

  1. Home
  2. Computing & Technology
  3. Visual Basic

©2009 About.com, a part of The New York Times Company.

All rights reserved.