Icon Overlays don't work properly in XYplorer

[admin]

1) I installed dropbox on Win7/64 but see no overlays/context menu in XY at all. Apparently it installed itself as 64 bit app. I cannot find a way to install 32bit dropbox on win7/64.

On Vista x64 and Dropbox v0.7.110 definitely installed the 32-bit overlays as well.

I have entries for Dropbox in both:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\ShellIconOverlayIdentifiers
and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

You aren't running XY using Run As Administrator are you?

No, as "User".

And yes, the keys (DropboxExt1 etc) are here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

However, the function that works fine in XP does not return the overlay index in Win7. Or do I have to configure dropbox to show the overlays?

[TheQwerty]

However, the function that works fine in XP does not return the overlay index in Win7. Or do I have to configure dropbox to show the overlays?

I thought the default value was to have them on, but if you open the Dropbox preferences from the notification icon you can verify that.

You did try restarting XY after installing Dropbox, right? I'm not sure if XY's Restart command is enough here.

[admin]

Ah, got it. Actually now see them in the compiled XY (which is run as User), but not in the pre-compile version interpreted from the sources which is elevated to Admin because I have to run the programming environment as Admin for other reasons. Hm. Tricky...

But at least it confirms your observation that they are not seen as Admin. Very strange.

[admin]

I also can confirm that the arrow overlay for LNK files indeed take precedence over the dropbox overlay under Win7. This was not the case under XP.

[grindax]

.

[nas8e9]

But at least it confirms your observation that they are not seen as Admin. Very strange.

TheQwerty and I hashed that out (well, *I* think we did ) some posts back. In a nutshell: UAC in Windows Vista and 7 strips administrative privileges from administrative accounts among other "fun" things. As a result, starting a program while logged in as an administrator without elevating it, does not grant full privileges to the started process. Due to the security boundary between elevated and non-elevated code, XYplorer running in your IDE (elevated) can no longer load already running code in-process that isn't elevated: the icon handlers.

[TheQwerty]

Yay, several months later, and two very long discussion threads later, you've finally observed the simple problem. To be clear, it is in XYplorer on Windows 7 that the .lnk and .url files exhibit this behaviour. In Windows Explorer itself, on Windows 7, the Dropbox overlays appear as expected on .url and .lnk files.

Following this incredible miracle...

Yep... and talking down to Don is sure going to help any of us figure this out or get it fixed.

[grindax]

.

[admin]

Apologies that it came out that way. I was frustrated by the earlier comment about not wanting to read the entire thread (despite this thread being the 2nd attempt to get to the bottom of this problem). There's a lot of good info in all of the posts and it seemed to me that this was going to waste. And then the comment about Dropbox being a 64-bit app on Windows (which it's not), appeared to be another evasion of this topic, and thus put me over the edge.

Anyway, I am happy that the problem has now been seen and verified. I'm hopeful that the dynamic updating issue can be reproduced and rectified too.

On a separate note, I think with Don being new to 64-bit Windows (and having given Vista a miss) he will no doubt have a lot to learn over the coming weeks and months about how the underlying architecture has changed. I will try to be more patient. In the meantime, as a gesture of goodwill ( ), I offer a handy tip to quickly tell whether a running program is 64-bit or 32-bit: Open Task Manager and go to the Processes tab. 64-bit Window shows you which apps are 32-bit by putting '*32' at the end of the process names.

Overlays: The returned value for LNK and URL is definitely different between XP and W7. The question is how Explorer still assigns a special overlay to them. One possibility is that Explorer resolves the LNK and then gets the overlay index for the link target. I tried this and it works, but the result slightly differs again from Explorer: When the target gets updated then both LNK and target get the "refreshing" icon of course. In Explorer however only the target gets it. This tells me that Explorer probably still takes another route. Just don't know which.

Tip: Thanks.

[grindax]

.

[grindax]

.

[grindax]

.

[TheQwerty]

(can 32-bit apps really not access the same registry keys and figure out what to do?).

It's not just reading the registry; the registry key tells it where to find the information (another registry key) for loading the DLL containing the code to determine when and what to display as the overlays. But 32-bit apps cannot run 64-bit code, so they cannot load the 64-bit DLLs. This is the same for context menu handlers.

So unless Mozy includes a 32-bit DLL or allows installing both versions at the same time like Tortoise* extensions do, then it will not show in XY until the 64-bit version comes, which won't be before 2011.

It's possible TC is using an unmodified shell list control and doesn't handle retrieving the overlays at all. I'm at a lose as to how else it could differ so not much more I can suggest to Don.

As for the refreshing I have a feeling it might be a case of XY receives all the right change notifications, but doesn't actually see them as separate events. So it could be requesting the new icon (blue modified one) when it receives the notification for synced, but by the time Dropbox responds with the blue modified one XY has discarded the additional notifications. Not sure if that's even possible with the way Don handles things.

[admin]

As for the refreshing I have a feeling it might be a case of XY receives all the right change notifications, but doesn't actually see them as separate events. So it could be requesting the new icon (blue modified one) when it receives the notification for synced, but by the time Dropbox responds with the blue modified one XY has discarded the additional notifications. Not sure if that's even possible with the way Don handles things.

I had checked that with dropbox under win7/64 but "unfortunately" I have no problem here with auto-updating to the right overlays.

Of course, Auto-Refresh must be enabled, and also ensure that this key (which is just a tweak) is 0 in your XYplorer.ini:
iDisableSHChangeNotifyRegister=0

[TheQwerty]

Of course, Auto-Refresh must be enabled, and also ensure that this key (which is just a tweak) is 0 in your XYplorer.ini:
iDisableSHChangeNotifyRegister=0

Well I had that tweak set to 1, but changing it to 0 doesn't seem to affect this.
If I create a new item I get the blue syncing icon until I force a reload/refresh of the list. I find it surprising that changing the file turns the icon blue successfully, but like above if I don't refresh the list it won't turn green.

What else can we do to help identify the actual issues behind this and the shortcut overlay problem?