How do I prevent unchecked checkboxes in my listview control from disappearing?


A customer asked, "I have a listview control in report view with the LVS_EX_CHECK­BOXES extended style. I noticed that unchecked checkboxes are not visible until I hover over the corresponding item. Is it possible to get the checkboxes to be visible all the time?"

I was kind of puzzled by this question because the default behavior of the list view control is to show the checkboxes all the time. I could have sat down and written a test program to prove it, but that would have taken too much time, and it wouldn't have advanced the story any. (The customer would merely have written back, "Well, that's not what I'm seeing.")

This appeared to be a case of a customer providing incomplete information, forcing me to invoke my psychic powers to fill them in.

"My psychic powers tell me that you have also set the LVS_EX_AUTO­CHECK­SELECT extended style. When LVS_EX_AUTO­CHECK­SELECT is set, then unchecked checkboxes are hidden."

Remember, when you ask a question about a component and you have done any customization to that component, please remember to mention that when you ask your question. Otherwise nobody will be able to reproduce your problem, because they will assume you left everything at the defaults.

It's like calling the Ikea customer service line, saying "My Ikea Frusträt rolling cabinet doesn't roll properly on my hardwood floor when I put more than about 25 pounds of stuff on it." The person on the phone looks up the specifications for the rolling cabinet and sees that that is well within the design limits. "I paid for you guys to assemble and install it, so it can't be an assembly or installation error." The person on the other end scratches their head for a while. And then you mention, "Oh, but I didn't like the color of the wheels, so I replaced them with some other wheels I bought at Home Depot."

Oh, yeah, thanks for not mentioning that.

Comments (22)
  1. Eponymous Coward says:

    "Remember, when you ask a question about a component and you have done any customization to that component, please remember to mention that when you ask your question."

    "Oh, yeah, thanks for not mentioning that."

    You see, the problem is that they changed a lot of things in addition to the style. If you already know what "the component" is, or if you only changed one thing, you can probably guess that's where the problem comes from. But if you have built a complex system out of many interacting parts you don't fully understand, and something is not doing exactly what you want it too, you only have three options: 1. Keep changing stuff until you can figure it out, 2. Spend time learning exactly how these parts work, or 3. Pay someone who understands how they work so they can help you.

    It is like calling the Ikea customer service line because your rolling cabinet doesn't roll properly, except that cabinet has 76 pairs of wheels, was assembled and heavily customized 12 years ago by some other division you've never seen, and you actually have no idea that wheels can affect rolling.

    [I'm not talking about some subtle setting in a dark corner of the control. The customer is having trouble with listview styles, but they won't say what styles they're using. -Raymond]
  2. Joshua says:

    Some people never learn binary chop.

  3. alegr1 says:

    "When LVS_EX_AUTO­CHECK­SELECT is set, then unchecked checkboxes are hidden."

    Unfortunately, my psychic powers are not good today. I can't find a single reference in MSDN which would state that. How was the customer supposed to know that?

    [LVS_EX_AUTOCHECKSELECT gives you the checkboxes the way Explorer does on Windows Vista, and you can plainly see see that those checkboxes appear only when checked or on hover. But my point wasn't "You should have known that". My point was "You withheld information about how you customized the listview control." -Raymond]
  4. msdn.microsoft.com/…/bb774732%28v=vs.85%29.aspx

    A comment at end says:

    "LVS_EX_AUTOCHECKSELECT should not be used with comctl v6 as it causes the checkbox to disappear."

    Sound like a bug. And instead of fixing the bug or updating the documentation, you write an article about the customer that complains about the bug…

  5. Eric Fournier says:

    @arghhhhhhhhhhh

    Because obviously the listview control falls under Raymond's responsibility, like every component or API he has ever written about!</sarcasm>

  6. Tim says:

    Sounds like another problem that would have been solved instantly if they had just created a minimal program to reproduce the problem, which I think is just common courtesy when you ask others for help.

  7. alegr1 says:

    Because obviously the listview control falls under Raymond's responsibility

    If Raymond knows this undocumented detail of its behavior, then yes, it does.

  8. John says:

    The moral of the story is that the documentation always sucks (this is NOT a Microsoft-specific problem).  Still, from the description given in the documentation available it certainly sounds like a bug.

    [Yes, the documentation sucks here. This was not a "Just read the documentation" issue. This was a "Please don't withhold relevant information" issue. -Raymond]
  9. John says:

    @Eric:  It's not his responsibility, but if you're going to berate somebody for failing to read the documentation you might want to first make sure the documentation is accurate.

  10. Joshua says:

    For the longest time we had the saying at our work "Documentation always wrong."

    We got it when our own engineers would consult the documentation rather than the code when customers asked us questions and gave them wrong answers.

    We finally got rid of it by purging almost all the documentation and starting over again.

  11. ChrisMcB says:

    alegr1, it sounds like you now know about this undocumented detail of its behavior. So I guess it is now your responsibility to fix it.

  12. Mark Bertenshaw says:

    @John – Read Raymond's comment:

    [Yes, the documentation sucks here. This was not a "Just read the documentation" issue. This was a "Please don't withhold relevant information" issue. -Raymond]

  13. The problem with complaining that they with-held relevant information is that they had no way of knowing that the information they "with-held" was not relevant, so it wasn't really their fault.

    What if the relevant information had been that this was a bug that was fixed in a Windows Update that they hadn't applied but simply didn't know contained the fix ?  Should they have also included a manifest of all Windows Updates that had been applied to the machine, just in case ?  Maybe there was some third party software that was (I don't know how) interfering with the behaviour of the control.  Should they have also provided a complete list of all installed software (and not "installed" but merely present software), just in case ?  Maybe – and this is highly unlikely I know – but it could have been some errant corruption of a binary (or binaries), so a complete set of checksums as well, just in case ?

    The only thing that makes this NOT a "read the documentation" issue is the fact that the documentation itself WITH-HOLDS RELEVANT INFORMATION.

    So yes, it is an issue of relevant information being with-held, but the originator of that problem was NOT the customer.

  14. cheong00 says:

    @ChrisMcB: A non-Microsoft employeee person fixing undocumented behaviour of Windows sounds more like hacking it than fixing it.

  15. cheong00 says:

    Btw, if the bahaviour isn't documented in MSDN, how could the customer know it's relevent? It's common practice to strip down the code to include only relevent part when sending the source to outside. It seems reasonable for me that the customer may just think LVS_EX_AUTO­CHECK­SELECT is irrelevent detail and exclude it from the scene, because there isn't any reason to think an auto-check option would make the boxes disappear.

  16. John says:

    @Mark:  The comment wasn't there at the time I made the post.

    Anyway, I agree with the general idea of this blog entry but the problem is knowing what is relevant to the problem.  I think when you're a subject matter expert sometimes you get tunnel vision.

  17. Drak says:

    @Everybody saying the customer could not have known the information was relevant:

    lvs_ex_autoCHECKselect would seem to me to have something to do with CHECKboxes. Therefore, if you have a problem with CHECKboxes, this something to do with CHECKboxes is highly likely to be relevant to your problem with the CHECKboxes.

    [Exactly. -Raymond]
  18. cheong00 says:

    @Drak: Have you ever been in the position to cleanup the source code to ask for help? The process involves removing everything your mind judge as "irrelevent". Anything matches that filter will be removed, that's it. Having the word "CHECK" in it won't make it special to make it state, otherwise people would have left the original default selections in the sample source code too, which in the real life, is rarely left there.

  19. Henning Makholm says:

    cheong00: If you're cleaning up source code in order to ask for help and not verifying that your cleaned-up source code still exhibits the behavior you're asking for help about, UR DOIN IT RONG.

  20. xp.client says:

    People still use SysListView32 after Vista introduced that uber-annoying full row selection for LVS_LIST view style? No empty space to click! Use your own control people. ItemsView of Windows 7 corrects this but it's private undocumented.

  21. Programmerman says:

    "I'm having an issue with the LVS_EX_CHECKBOXES extended list view style. Here's all the styles I'm using on my list view: [list]."

    Seems like the way to do it to me.

    Although stripping it down to the minimal components to make sure that reproduces the issue seems like a good idea. If your stripped down version doesn't reproduce and you can't figure out why, then you can ask what components might override the behavior. Then you're no longer withholding information, but asking for it.

  22. Skyborne says:

    @Programmerman, but it's so much faster just to pester someone for help.  Besides, if you have MS support costs in the budget, why not use them?

Comments are closed.