Unable to customise Notification Area icons

[nikos]

I am not trying to deny the problem, I am trying to understand something I cannot reproduce. Do me a final favor: with the 32 bit lite or whatever as explorer replacement, right click on the notification area and use "customize notification icons" menu command. Does it fail? if yes, does it matter if lite version is running or not?

[Kilmatead]

I could have sworn I gave up bricklaying, but sometimes pounding things into your head brings it all back...

On Win7 there is no context menu for the notification icon area (at least none that I could find), you just click the taskbar arrow next to the clock and then click "Customise" in the wee window...



...but the long and short of it is that it's the same as selecting it from the start menu.

If x86 x2 is running, nothing happens (the active pane doesn't even blink). Nothing at all, no errors, no dings, dongs, or midnight bells.

If x86 x2 is not running then x2 opens automatically but again, nothing happens. The active pane is just set to whatever it's supposed to be on startup (a normal folder).

No crashes, and x2 is perfectly usable - except those Windows options are completely unavailable (by any means), unless (as stated above), the x64 version of x2 is running first - then they work fine.

(In case you're bored with notification icons, I should say that the windows theme cannot be changed either. Nor can the desktop background be changed from the start menu, but it can be by right-clicking on a picture.)

At least mildly amusing is if I try to access the "change desktop background" from the Start Menu's "Personalisation" section, I get this extremely informative error:



...which is the most excitement I've had all day (in fact, you get it twice, about 3 seconds apart on a single click). Pretty much all the other entries just die quietly, but that one (and only that one) seems to put up a fight first. (And before you ask, x2's Help -> Last Error shows nothing - tabula rasa.)

[nikos]

we must be living in parallel universes... did you actually right click ON the notification area?

[Kilmatead]

Same difference, same result. How many times in one thread can I say something "fails no matter how it's accessed"? Use a Ouija board if you want to, pay your brother to use osmosis, shoot it with one of those faulty m16 carbines you sold to Turkey...

No matter how...
No matter how...
...

[nikos]

so after some more investigation (thanks kilmatead) it looks this is a terminal fault that cannot be fixed.
The only question now is whether to disable explorer replacement in 64 bit mode altogether...
when you access the control panel (the part that works) from xplorer2 lite (whilst being explorer replacement), can you access problematic items like "notification area icons?" -- i mean once you are in explorer's control panel one way or another. Or is the lite version eating them up from there too?

[Kilmatead]

Or is the lite version eating them up from there too?

Short of clicking Undo Explorer Replacement in the options, about half the control panel is toast. Toast with marmalade. Toast with jellies and jams. Toast with Marmite.

It's just toast, so, no, they are not available no matter how you approach the item. (Could have sworn I already mentioned something about that...)

Apparently your method of "passing-off" these canonical/CLSID addresses to be handled directly via explorer still interferes with it, somehow due to being a 32-bit entity in an x64 world.

The only remotely interesting thing I found was a vague reference about how explorer itself resolves literal GUID-text paths directly when it finds them ("::"/bracketed prefixtures) usually from command-lines, apparently using a DLL'd filter from within Sys32, or somesuch. I lost the link, but again, it points to SysWOW64 chicanery, which in this case might be hard-coded to process-type, "sort of".

Things like this might explain why so many processes have specialised x64helper modules attached as services, to pick up the slack where the main band fails to fill all the seats in the concert-venue.

[nikos]

so the old bag must go!

[Kilmatead]

Not helpful, but from a technical experimentation perspective, I can't get "::{26EE0668-A00A-44D7-9371-BEB064C98683}\0\::{05D7B0F4-2121-4EFF-BF6B-ED3F69B894D9}" to execute in the shell via a 32-bit process at all (irrespective of x2 Lite), not even when that process invokes Wow64DisableWow64FsRedirection first (which, according to the dox, should cancel out any DLL loading redirection as well - just in case the ::{GUID}'s were somehow being misinterpreted).

No problem at all if executed through the shell as an x64 process. Wacky.

It appears some things are just plain out "out of bounds" for x86 - no matter how many coats of varnish you lather over them.