[Estimated Reading Time: < 1 minute]

The usually exhaustively complete Raymond Chen over-looked a crucial factor in his most recent posting on his excellent Old New Thing Blog regarding SHAutoComplete.

In his post he discusses a technique for disabling auto-complete in a common dialog, but along the way discusses why calling SHAutoComplete twice cannot be used to remove flags previously applied.  As I say, Raymond normally is very precise and exhaustive in his coverage,  often pre-empting “nit pickers” by calling out in advance anything and everything wrong with a question or with approaches that are implied in the question (or in his answer).

In this case, I would have expected him to draw particular attention to the warning in the MSDN docs for SHAutoComplete:

“SHAutoComplete should not be called more than once with the same HWND. Doing so results in a memory leak.”

But far from it – he actually advocates calling SHAutoComplete a second time to modify flags if needed!

Sadly, comments are currently disabled on The Old New Thing due to an extraordinarily lengthy upgrade process being carried out on the underlying blogging system, so I was unable to draw attention to this (and no doubt earn myself a Nit Picker “badge” in the process), but in this case I think it’s worth highlighting.

5 thoughts on “SHAutoComplete: Calling Once, Calling Twice…”

  1. Good catch. The documentation is out of date. The memory leak is fixed in Windows Vista. I’ll update the article (and submit a doc update).

  2. Wow, a reply from Raymond himself – I feel honoured. 🙂

    Seriously, thanks for the clarification Raymond tho of course the memory leak having been fixed in Vista presumably means that the problem remains in XP so for code that has to run in both XP and Vista the problematic behaviour in XP remains a limiting factor, no?

    If targetting Vista alone, how would “XP Compatability Mode” affect things, if some user for some reason chose to run such an application in that mode?

  3. XP Compatibility Mode modifies selected behaviors to more closely match XP. It doesn’t replace all the DLLs with the copies from XP. Bugs that are fixed remain fixed unless somebody specifically adds a “but don’t fix it if running in XP Compatibility Mode” test. (XP Mode on the other hand runs an actual copy of XP, so all the bugs in XP are still there.)

Comments are closed.