Why do non-folders in my shell namespace extension show up in the folder tree view?

A customer was having trouble with their shell namespace extension:

When we click the [+] button next to our shell namespace extension in the folder tree view, the tree view shows both files and folders, even though it’s supposed to show only folders. Our IShell­Folder::Get­Attributes­Of does return the correct values for SFGAO_FOLDER (including it for the folders and omitting it for the non-folders). What are we doing wrong?

The tree view enumerates the children of a folder by calling IShell­Folder::Enum­Objects and passing the SHCONTF_FOLDERS flag while omitting the SHCONTF_NONFOLDERS flag. This means that it is only interested in enumerating child folders. Child non-folders should be excluded from the enumeration.

It so happens that the customer’s shell namespace extension was not respecting the SHCONTF_FOLDERS and SHCONTF_NONFOLDERS flags; it always enumerated all objects regardless of what the caller requested.

Fixing the enumerator fixed the problem.

Comments (12)
  1. Henke37 says:

    And the moral is:

    Don’t screw up.

  2. Nick says:

    I’m not familiar with shell interaction, but from reading this it looks like they were just checking for SFGAO_FOLDER instead of SHCONTF_FOLDERS — is that right?

    Googling for SFGAO_FOLDER doesn’t yield much information about what it is for, so I’m not sure if the customer’s confusion was reasonable or not.

    [A basic understanding of the shell namespace was a prerequisite for today’s article. But just for you (don’t expect me to do this every time): Get­Attributes­Of is like Get­File­Attributes and Enum­Objects is like Find­First­File­Ex (except that the flags are mandatory instead of advisory). The customer basically said, “How come files are showing up in the folder tree? My Get­File­Attributes returns FILE_ATTRIBUTE_DIRECTORY only for directories.” The reason was that their Find­First­File­Ex was ignoring the Find­Ex­Search­Limit­To­Directories flag and was returning all items even though the caller said “Give me only directories.” -Raymond]
  3. Falcon says:

    I was able to follow Raymond’s explanation even without knowing the details. The customer had obviously implemented IShell­Folder::Enum­Objects, but hadn’t done so correctly.

    This situation is a bit like asking why your VCR doesn’t record the program you want, even though you selected the correct channel on your TV tuner – overlooking the fact that the VCR uses its own tuner to obtain the AV signals.

  4. asf says:

    @Falcon: unless we are talking SCART, then the VCR can actually record the output of the TV

  5. Erik says:

    I wonder why SHCONTF was renamed to SHCONT in the Vista SDK? And what does SHCONT stand for anyway? I’d wish MSDN would spell out these acronyms at least once, it helps me memorize them.

    [I’m not aware of them being renamed to SHCONT at any point. And it’s not an acronym. I can’t say for sure, it it sure looks like it stands for “shell (folder) content flags.” In other words, they describe what content you want. -Raymond]
  6. Falcon says:

    @asf: A lot of TVs (probably most of them today) also have AV output ports which could be connected to a VCR’s input, but I was talking about a setup that was once common – Antenna -> RF IN, RF OUT -> TV.

    Even so, you might still have to make sure that the AV input is selected as the source.

    To relate back to the topic – the customer might have assumed that the tree view would check the attributes of each item to see if it was a folder, but chose not to for performance reasons and because it was not necessary. I’ve thought of a hypothetical SQL example:

    SELECT Name FROM Items WHERE Type = ‘folder';

    (No, I wouldn’t use strings in real life, this is just for simplicity!)

    In this case, you’d trust that the database engine would only give you folders, like it was supposed to, rather than retrieving the ‘Type’ column and checking every item to see if it was a folder.

    Anyway, I believe Raymond’s point was what we’ve seen many times on this blog: if you don’t follow the documentation, expect things to break. (Pre-emptive snarky comment: Unless you’re writing software for Windows, in which case Microsoft will fix your crappy code for you, thus bloating the OS further!)

  7. ASF says:

    @Falcon: In Europe, SCART is the most common connection between VCR and TV, not only can it transfer audio and video (composite,s-video and RGB) but it also supports control commands to change channels/AV input etc

  8. hdmi says:

    HDMI is currently the most common video cable standard.

  9. Erik says:

    The MSDN Library for Visual Studio SP1 has an entry for the SHCONT enumerated type with this note:

    "Note  The name of this enumeration was changed to SHCONT in Windows Vista. Earlier, it was named SHCONTF. The name SHCONTF is still defined through a typedef statement, however, so it can continue to be used by legacy code."

    But you’re right, there’s no trace of SHCONT anywhere in shobjidl…

    And http://msdn.microsoft.com/bb762539 says: "The name of this enumeration was changed to SHCONTF in Windows Vista. Earlier, it was named SHCONTF." Oops, but somebody has already reported this mistake.

  10. Marquess says:


    On a VCR?

  11. Owen says:

    On the subject of SCART: SCART allows the composite video stream to go both ways, and also has a signal switching pin. Back in the analog days, you used to get receivers for encrypted TV which used this: The TV would send the currently received signal to the STB, it would detect that it was encrypted and decrypt it, send the decrypted signal back and turn on the signal switching pin to tell the TV to display its signal instead.

    An interesting side-effect was that, depending upon your TV, this would make recording the show with your VCR

    * Not work (Recording encrypted signal)

    * Work only if in the right connector (Recording the decrypted signal which, for example, goes down to higher numbered connectors)

    Of course, it is all a bit moot these days.

  12. The Imp says:

    Not sure exactly when this possibility first existed or was first removed (I think it began with 95/IE4 and was removed from W2K), but you could actually force Windows Explorer to do this, by typing a file:/// address (pointing to a local HTML file) into the Address bar in a Windows Explorer session. You’d render HTML in the files panel, but keep the Folders panel, which would list both folders and files in the tree. Still not sure if it was a bug or an unintended feature (if there’s a difference).

    I’m a bit fuzzy on exactly how to reproduce it after all this time, actually, and I don’t have any easy way to test it. But for folders with small numbers of files, it was sometimes handy when doing web development, or or a makeshift image view before XP added one.

Comments are closed.