Icon Overlays don't work properly in XYplorer

[grindax]

.

[TheQwerty]

It would help if you listed, in the same order, the keys found under:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers


On XP, I can add that synced items in Jungle Disk are also missing their overlays in XY (and in WE on Vista), but so far I haven't been able to track down more info.


EDIT: Also regarding number 2. I believe in 7 they made the shortcut arrow overlay an official overlay instead of a custom icon (maybe?). It's possible that the Windows priority for that overlay is taking precedence over third-party software. http://blogs.msdn.com/oldnewthing/archi ... 34348.aspx

[grindax]

.

[TheQwerty]

Well that article was really only about changes that occurred in Windows 7. There's better information about how a programmer adds overlays here: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

I don't know if that means the entire OS can only make use of 15 overlays, or if a single type of image/file can have 15 associated overlays.

From the above page, I get the impression that there is only space for 15 overlay images, and from the previous article, Windows 7 reserves 5 of them.

If it's true that Windows only comes with 5, I can't imagine that installing Mozy and Dropbox (which in total use 3 or 4) has taken me over the OS limit.

The registry key will show you how many are installed. While it's possible that this limitation is part of the problem, I don't believe that's the case, and there's more to it than that.

The frustrating thing about that MSDN article is that it talks about overlays winning or losing when multiple apply, but there's no indication how they take priority.

This newer link explains this better. Each handler for a program wishing to add overlays has to implement the IShellIconOverlayIdentifier interface, which contains 3 methods.

1) IsMemberOf - Takes the path & attributes of an item and returns whether or not an overlay should be displayed.

2) GetOverlayInfo - Returns the path to the overlay image.

3) GetPriority - Which returns an number from 0 (highest) to 100 (lowest) defining the priority for this overlay.

Where it gets tricky is that the defined priority is handled by each handler, so if they all say they're the highest then the first one the shell checks wins, but to make it even more confusing it says:

The Shell has a set of internal rules that determine the priority for many cases ... GetPriority is used for those cases in which the Shell's internal rules do not apply.

Who knows what those internal rules are and how they come into play here? It seems the real purpose of this is if your handler defines multiple overlays you can then use the priorities to define which of them is more important.

But somehow Windows Explorer on Windows 7 is showing the expected overlays in the 3 situations I outlined. For the Mozy files, there is no other overlay, so there shouldn't be any conflict issue. For the Dropbox .url files, somehow Windows Explorer knows that Dropbox's overlays take precedence. And for the dynamic updates of files that are being synchronised, Windows Explorer must be seeing some events that Dropbox is triggering.

Well I think the 3 cases you outlined may be entirely separate problems.

1) I have a completely unsubstantiated feeling that this is related to Mozy's implementation or registry settings more than XY.

2) I think this might be something funny in the Shell's internal rules to be honest. Perhaps, they have a rule that gives their overlays a higher priority when called from non-native controls or outside of WE.

3) I agree with your assessment. I want to take a look with process monitor to see if I can identify anything to give Don some help, but I need to find the time for that.

[grindax]

.

[TheQwerty]

Well, without having you look up what those CLSID entries contain, that looks fine. In the other thread you mentioned that the first two problems are in Win 7 x64, right? That means I'm completely wrong and that's not the key XY would be using...

So if you are using x64 instead check out:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers


When you open the Windows' properties dialog for one of the .url files what overlay icon does it show there?

[grindax]

.

[TheQwerty]

The first issue (with Mozy overlays) seems to be present in all operating systems. I'm currently running Mozy on just my Windows 7 x64 machine

Well the first part of this problem is that Mozy doesn't register its overlays for 32-bit use as well. Maybe if you installed both the 32-bit and 64-bit versions it would work, if they have them I'm not familiar enough with Mozy to know. The key here is when XY is started it (or the shell on its behalf) reads HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers and loads the associated DLLs so that it knows who to ask about overlays.

If they indeed don't work on 32-bit systems as well, then there's more to the problem.

The second issue (.url files) affects all versions of Windows 7, both 32-bit and 64-bit. On Windows XP it works OK.
...
If I open the properties of the file, I see the standard Windows 'shortcut arrow' overlay. But Windows Explorer itself shows the green tick.

I truly believe this is one of those internal shell rules that may return a different icon based on whether WE is asking or a third-party. Perhaps, the rule is not as devious as that makes it sound, but it seems to make sense when you consider it's showing the shortcut arrow in the properties dialog.


I'm not familiar enough with how Don is determining the icon to know if there's more he could do if its determined that the icon is using the shortcut arrow, but could be using something else instead.

[TheQwerty]

Another question, have you tried comparing XY's behavior to any file managers other than Windows Explorer?

In looking at my Jungle Disk issues I'm arriving at the conclusion that their overlay interface is buggy since the problems aren't just in XY, and their registry entries look to be correct (or at least very similar to working overlays).

[lukescammell]

I don't know if this has any relevance, but Dropbox overlays seem to work just fine in XYplorer... of course, it slows things down enough that I turn them off, but they do work.

[admin]

I don't know if this has any relevance, but Dropbox overlays seem to work just fine in XYplorer... of course, it slows things down enough that I turn them off, but they do work.

Do you see them when you run this scripting line?:

Code: Select all

::sysicons 1;  //show Icon Overlays

[lukescammell]

No, but I do have overlays turned off...

Wait, yes I do

Well, I didn't see them, then I turned overlays back on, ran the script again and saw them, turned overlays off again, ran the script again and then saw them. Of course, I might have just missed them the first time...

Either way, Dropbox overlays work for me (Vista SP2 x64).

[TheQwerty]

Well, I didn't see them, then I turned overlays back on, ran the script again and saw them, turned overlays off again, ran the script again and then saw them. Of course, I might have just missed them the first time...

One thing to note is that the set of overlays are only loaded when the program is loaded. Both XY and WE scan that above mentioned registry paths to load the icon handlers at startup, so you have to restart them if changes occur in the registry.

Either way, Dropbox overlays work for me (Vista SP2 x64).

With Dropbox the issue is that the shell link overlay (arrow for .url and .lnk files) is shown instead of the Dropbox sync icon within XY, but WE shows the Dropbox ones instead. There's also an issue with XY refreshing the icons, but I haven't really looked into that yet.


sysicons 1; is only partially working here, it seems to display the four default Windows ones (though I'm missing #3), but will only display the Dropbox ones after I have seen them in the list. However, still no luck understanding Jungle Disk, and grindax or someone else will have to comment on Mozy or Tortoise*.

[lukescammell]

Well this is what it looks like for me without running the script (XY left, WE right):

If anything XY is showing more information to me, since it is using the TortoiseGit overlays on the two directories that are repos whereas WE is not.

Are these not the Dropbox/TortoiseGit icons?

[grindax]

.