STRICT_TYPED_ITEMIDS is the shell namespace version of the STRICT macro used by USER and GDI


Starting with the Windows Vista PlatformSDK, defining the symbol STRICT_TYPED_ITEM­IDS before including shell header files changes declarations that previously had simply used ITEM­ID­LIST now use one of various types which are more clear about what type of ID list is being used.

Think of it as the STRICT macro for the shell.

The more precise names emphasize the form of the ID list:

  • ITEM­ID_CHILD represents an item ID relative to some implied shell folder. The item ID is followed by a null terminator and is therefore exactly one SH­ITEM­ID long. In file-system speak, this is a "file name."
  • ID­LIST_RELATIVE represents an item ID list relative to some implied shell folder. It can consist of any number of SH­ITEM­ID structures concatenated together, followed by a null terminator. This item ID list must be used in conjunction with the IShell­Folder it is associated with. In file-system speak, this is a "relative path."
  • ID­LIST_ABSOLUTE represents an item ID list relative to the desktop root folder. It too can be any length. This item ID list must be used in conjunction with the IShell­Folder returned by SH­Get­Desktop­Folder. In file-system speak, this is a "fully-qualified absolute path." (An absolute ID list is the special case of a relative ID list where the implied shell folder is the desktop root folder.)
  • ITEM­ID_CHILD_ARRAY represents an array of pointers to ITEM­ID_CHILD objects, where all of the ITEM­ID_CHILD objects are children of the same shell folder parent. The array must be used in conjunction with that parent shell folder.

These new types were introduced to help catch common programming errors when using the shell namespace. For example, if you try to pass an array of absolute pidls to IShell­Folder::Get­UI­Object­Of, you will get a type mismatch compiler error because that method takes an ITEM­ID_CHILD_ARRAY, and the thing you passed is not an array of ITEM­ID_CHLD pointers.

You are encouraged to turn on strict mode when compiling code that uses the shell namespace, but to preserve source code backward compatibility, the setting is off by default.

Comments (12)
  1. WndSks says:

    I'm pretty sure some of those methods that only accepts child pidls today used to accept absolute pidls back in the Win9x days…

    Anyway, I'd love a followup to the IContextMenu series; how to display the context menu for two files when they don't share a common parent folder (Like Win+F/File search). Using CDefFolderMenu_Create2 is not easy either because MSDN does not tell you which HKEYs to pass nor their order. (HKCRFolder before HKCRDirectory before HKCRAllFilesystemObjects? And what about files? SystemFileAssociations? And that is just for XP, after that you also have to deal with Kind?)

  2. Matt says:

    @WndSks: They accepted them because they are the same type – but that's like saying that CreateFileW() accepts a SQL statement as the filename. Just because they are the same type, doesn't mean it does what you expect it to.

    The whole point of the "strict" macro which is the whole point of this article is that it makes functions give you a compile time error rather than just break at runtime if you do something silly like send an absolute PIDL to a function that expects a child pidl.

  3. WndSks says:

    @Matt, when I said accept I meant that they did something and returned S_OK.

  4. JS says:

    Doing something and then returning S_OK does not mean that it did what you wanted it to do.  Just that it didn't encounter an error while doing something that may or may not have been what you wanted.

  5. WndSks says:

    IShellFolder::GetDisplayNameOf: "At one time, pidl could be a multilevel PIDL, relative to the parent folder, and could contain multiple SHITEMID structures. However, this is no longer supported and pidl should now refer only to a single child item."

  6. yuhong2 says:

    OT, but I wonder why VBA was forgotten when mouse wheel support was added to Office 97.

  7. Silly says:

    OT, but I wonder why VBA was forgotten when mouse wheel support was added to Office 97

    Yeah man; that's been eating away my soul for 16 years. And this forum is where the answer will lie.

  8. AC says:

    Yuhong Bao: "OT"

    Nominated for understatement of the year. I'll check back December, but I doubt someone will top that.

  9. Neil says:

    Maybe he meant to comment on yesterday's post?

  10. Yuri says:

    Oh the infamous ShiteMid, reminds me of IShitTestVisible, useful when you need to find not so obvious bug.

  11. Mordachai says:

    This seems pretty hard to use in practice.  For example, ILClone takes only a relative IIDLIST.  Why not an absolute IIDLIST?  What could the difference between these possibly mean in terms of cloning them?

  12. Mordachai says:

    Ah, well, there is an ILCloneFull().  But then MFC itself seems to use the non-strict model, which makes using it with this unpleasant (going to have to cast _AFX_SHELLITEMINFO members, e.g.)

Comments are closed.