The filtering I implemented will now remove options from the context menu when you click on anything but files the command can work on.
The way it works is by having two conceptual pieces; the filter and the particles. The file classes a command can work on is considered the filter. The actual files that you want to perform the command on are considered the particles. If the particles pass the filter, then the command is added to the menu. The way HMENU works makes it hard to create a submenu only if it has any children.
In code it was easier to just use the same class for both, which I dubbed FileFilter. A FileFilter is queried if it can contain another FileFilter (FileFilter::contains( FileFilter )). Drawing inspiration from set theory, the clicked on files belong to a set of file classes and if there is one command that can work on all those file classes then I consider that the command filter contains the file filter.
So if you right clicked on a selection of MPG and AVI movies you'd only get menu options that work on both file classes, like say, adding them to your favourite player's playlist. This is a bit different from standard Windows behaviour, which only shows options that can be made on the actual file you clicked. Try that, select an MP3 and a TXT file. If you right-click on the MP3 you get playback options, if you right-click on the TXT you get edit options. That's F'ed up!
But since command filters can have * (any file extension) while file filters can't, and file filters aren't supposed to be tested if it contains command filters, I might split it up to enforce the concept. And it confuses as it is now. :P
After fixing the help and icons I'll work on a new section I call "Aliases". Aliases are for file classes with different extensions like .jpg, .jpeg, .jpe which are all JPEG images. You'd create the JPEG alias and then use it as a command filter in the XML, less typing. ^^ The actual DLL configuring, such as setting a GUID, will also be configured through XML.