Couple of bugs/issues and some pathetic request :-)

[Stefan]

Hello,

I would like to make aware of some issues I experienced in xplorer² x64 v3.2.0.1, running on Windows 7.

Here goes ...

1) MTP devices (current smartphones/tablets) don't show up if connected. A folder pane showing MyComputer needs to be refreshed in order to do so, however, the device still doesn't pop up in the tree. It needs to be accessed, or the whole branch closed/reopened. Same problems if the device becomes disconnected. Note that the auto-refresh MyComputer option in the advanced settings has been turned on, but is obviously unable to catch devices who don't receive a drive letter.
I would like to ask for a confirmation since Windows explorer shows the same unpleasant behaviour, so this might be a problem only with my system here.

Solution: Check if the Shell Hardware Detection service is enabled and running. If not, set the startup type to 'Automatic' and reboot your system. This did the trick for me.

2) I tried to help myself with the aforementioned issue by bookmarking my smartphone, but making use of the bookmark after connecting the device always causes xplorer² to freeze/crash (even if I wait about 20 secs to make sure it is properly mounted)

3) The filter box takes folders into account, while CTRL+H doesn't

4) When renaming a drive within the tree panel, the edit field includes the drive letter. Afterwards the letter has disappeared, and won't reappear until the tree pane becomes refreshed. Please see Windows explorer for the difference.

5) Drive letters appear twice in drive menu. By the way, it would be nice if those MTP devices would appear in this menu as well!

6) In case the tree pane is active, switching the language through the Help menu has a funny impact: The message "This command is not applicable for the tree pane" appears, before xplorer² closes

7) Since v2.5.0.0, "in explorer replacement mode, 'Open containing folder' menu command from 3rd party programs will correctly open and select items in xplorer²". This is not working with True Launch Bar here, however this may be caused by the application itself (hardcoded? ).
It DOES work with control panel though, but to be honest I'm not happy with this. Those modules receive a special treatment by Windows explorer, something xplorer2 can't do and shouldn't even take into consideration. I'd say, leave it to the OS to treat and display the control panel modules the way they should. Since it's not very beneficial to have the users click those "Problems accessing this folder?" messages in order to fall back on Windows explorer anyway...

8) "New tab" resides in File menu, while the corresponding "Close tab" appears in Windows menu... maybe explainable, definitely questionable, surely whimsical

Well, that's it.

But I would like to end this with a request. Since day one I am making use of the "Automatically shift focus to view after activation" setting, as I consider and use the tree pane almost entirely as a navigation tool, not as a work area, as opposed to the two folder panes. For people like me these are completely separate elements of the interface, and this is why I am not making use of the rgbActiveBgcol feature, as much as I would like to. Seeing the tree pane being permanently greyed out, hell, this looks ugly and just wrong! So, pleadingly I would ike to request some advanced setting to exclude the tree pane from the rgbActiveBgcol effect.

In any case, thank you for paying attention, and keep up your great work!

[nikos]

1. if your windows explorer cannot autorefresh on insertion/removal of these devices then neither will xplorer2. You can make your life easier if you setup your phone so that it appears a simple USB storage device, then it will have a drive letter. Check your phone setup guide

5. I don't see this problem, can you elaborate?

7. for control panel see here http://forum.zabkat.com/viewtopic.php?f=18&t=10472

I am not replying for the trifles you brought up because as you may know I concentrate on the big picture and perfection is left for the utopians

if you don't like tree dimming out, use TOOLS > OPTIONS and from WINDOW page pick an inactive background color that is same as the active (white) color

[Kilmatead]

3) The filter box takes folders into account, while CTRL+H doesn't

Use (the similar, yet more fully endowed) <Alt+H> instead.

I am not replying for the trifles you brought up because as you may know I concentrate on the big picture and perfection is left for the utopians

Now Nikos, remember we talked about this... such illusory self-aggrandising is not how to go about making friends and influencing people. You have to at least pretend to be attentive to the concerns of your users! Absolutely astonishing how your wife ever married you. Stefan, pay him no mind - Nikos was obviously a lonely child in school and is now just just scarred for life and unable to socialise properly. He can, at least, programme tolerably well so we keep him around for that - but (as you can see) there's a reason he never gets invited to parties.

[Stefan]

Hello nicos & Kilmatead, thank you both for your replies!

1. if your windows explorer cannot autorefresh on insertion/removal of these devices then neither will xplorer2.

At least my windows explorer doesn't autorefresh. Since the device is proper recognized and mounted by the OS, but not shown in the OS' file manager, I'm still not sure if this isn't a local issue on my system. Can someone confirm this behaviour? i searched google for this, but no one seems to complain ...

Setting up the phone as a USB mass storage device was the first thing I tried, but unfortunately this is not possible. AFAIK most Android 4.x devices don't support UMS anymore.

Use (the similar, yet more fully endowed) <Alt+H> instead.

Thank you, this may come in handy! However, facing three visual filters (Ctrl+H, Alt+H, filter box) which behave differently is not good. This is confusing and therefore fateful. My advice would be to get rid of Ctrl+H, and add a checkbox to Alt+H similar to the "local search" checkbox, in case you would like to apply another filter to the current screening. While the filter box should always replace any previous filtering. That's it. Because sometimes less is more.

5. I don't see this problem, can you elaborate?

Sure. While in tree and folder pane all is fine, In drive menu the letters appear twice, and even three times in case of shared network folders:

DoubleDriveLetters.jpg

7. for control panel see here viewtopic.php?f=18&t=10472

Perfect!!!I

f you don't like tree dimming out, use TOOLS > OPTIONS and from WINDOW page pick an inactive background color that is same as the active (white) color

Yeah, as I said, that's what I already do. I was a big fan of rgbActiveBgcol until the day this setting became applied to the tree pane as well. Since then my rgbActiveBgcol is white. It's the lesser of two evils. Still I really would like to dim out the inactive folder pane, but just that one. Nothing else.

I am not replying for the trifles you brought up because as you may know I concentrate on the big picture and perfection is left for the utopians

Well, you bring up a matter here that applies to so many software applications, and I think most people will agree with me here. Really, it's always the same. Developers somewhat lose themselves in more and more unnecessary and exotic features, it's all about moving on, leaving behind code which may does the job, but is far from being rock solid - and users who have to deal with the result. Like the CLSID reference in the screenshots address bar, another flaw which exists since day one. Won't get fixed, since it's obviously more important to come up with such time-consuming flamboyance like the ribbon. In short, a big picture becomes all messed up if you don't take care of the details. xplorer² is well on the way to become one more perfect example for over-engineering and featuritis, and that's pretty sad.

[nikos]

the drive letter mystery is explained thus: when you renamed the drive label, you left in the drive letter, so that became part of the name. Then the drive letter was added again automatically. Solution: rename again and remove all the drive letters

[Stefan]

I wish it would be that simple, but no, the letters are not part of the label. I'm 100% sure about this. The drive properties show the labels how they are supposed to be. And in case I set ShowDriveLettersFirst in registry to 2 (= show no drive letters), they do become hidden within the panes. So the issue is limited to the drive menu.

On a side note, in xplorer², if a drive becomes renamed in-place within a folder pane, the change isn't applied in the tree pane, and vice versa. if a drive becomes renamed within its properties page, xplorer² doesn't even catch the change at all. In any case, it needs to be refreshed manually, unlike windows explorer.

[Kilmatead]

And in case I set ShowDriveLettersFirst in registry to...

And therein lies the rub. It rather goes without saying that expecting registry hacks from the XP era to be wholly compatible with 3rd-party software is (what I might refer to as) "a long stretch".

That being said, while these hacks do work in Win7 (to a limited degree, and are only really reliable if you restart the explorer process itself as well as x2 between changes) - you are correct in saying that x2 does not "pick up" edited label-changes correctly and requires a refresh to do so; and yes, I can see the "double letters" too upon renamed drives.

However, these things only happen when variations of this ShowDriveLettersFirst hack have been employed. Under ordinary conditions x2 labels and label-changes automatically register as expected, without requiring a manual refresh.

Thus, the good news is that you're not imagining things.

The bad news is that expecting WinExplorer registry hacks to be compatible with or supported by 3rd-party software is... umm... hmm...

In my experience, x2 is largely tolerant of many such registry changes (as well as other 3rd-party modifications from programmes like Classic Shell, etc). But it would appear you found one wherein it is not tolerant at all.

[Stefan]

I won't call this a hack from the xp era, since setting ShowDriveLettersFirst to 2 is what happens if you untick 'Show drive letters' in the folder options of Windows 7 explorer. And x2 does indeed adopt this setting, even within the drive menu, where "D: Work (D:)" becomes "D: Work". Problem is, well, it should look like that without unticking 'Show drive letters'.

Any idea how to return to normal behaviour? Getting rid of the redundant drive letter? And restore auto-refresh?

[Stefan]

Solved the problem with MTP devices not automatically showing up.

Ages ago I had disabled the Shell Hardware Detection service which primarily provides auto play functionality. Looks like its needed now in order to proper integrate those MTP devices - I reenabled it, and voila, some seconds after connection they show up in both file managers!

Doesn't affect both the drive letter issue and the missing update of renamed drives though.

[Kilmatead]

Since the ShowDriveLettersFirst DWORD is not a native value to the registry (the user is required to create it themselves, name and all, in order to access it), that qualifies it (reasonably enough) as a hack. The solution is to remove the value completely (delete the whole entry not just change it to 0), restart the explorer.exe process and restart x2 as well. That should return at least this portion of your shell to stock, and x2 will behave normally when renaming drives, refresh and all.

(And when I say "restart the explorer.exe process" that's based on empirical experience as it proved necessary when I was messing around with it myself to see if I could recreate your problem earlier.)

...since setting ShowDriveLettersFirst to 2 is what happens if you untick 'Show drive letters' in the folder options

That only holds true if the user had previously created the value themselves, as you had sometime in the distant past. If the drive letters are disabled in the options on a stock registry, the underlying value is still not spontaneously created (I just checked it to see).

[Stefan]

No luck. Removed the entry, restarted all instances of both windows explorer and x2, but no change. Rebooted the system, but still no auto-refresh when renaming drives in x2.

If the drive letters are disabled in the options on a stock registry, the underlying value is still not spontaneously created (I just checked it to see).

Interesting. Did you take a look at

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer ?

As several sources refer to the corresponding HKEY_LOCAL_MACHINE key, which should do the same, but for all users.

[What an odd option, to disable drive letters - must be so admins can obfuscate full paths from their users or something similarly cruel. Strange.]

Yeah. I never disabled drive letters either, but I used the option ShowDriveLettersFirst to, well, show the drive letters first. Looks way more tidy, especially in the tree pane.

Regarding the redundant drive letter, I'm asking myself if nikos may be on the right track. The letters are not part of the label, but that doesn't mean that the OS won't pass both letter and label as one integrated character string. What if it shouldn't do this? Or if such a string is both intended and expected, but the string format unexpected, so x2 fails to remove the letter(s)? In both cases, the above screenshot would be the consequence.

Maybe nikos can be of help and point out where the content of the drive menu is coming from, or how it is optained. Maybe this way I can narrow down the search.

EDIT: It's really odd. The missing auto-refresh does only apply to drives, not to folders. x2 catches any name change of a folder and updates every pane accordingly. Weird.

[Kilmatead]

I had tested HKLM, but now that I look at HKCU it appears that entry does indeed exist, so I was mistaken. Still undocumented though, so semantically speaking it's somewhere between a "tweak" and a "hack".

Like I said, I did encounter the double-drive-labels (and lack of refreshing), however both issues disappeared immediately upon restarting explorer after the key removal... so, especially as you rebooted, I'm at a loss to explain their persistence on your machine.

As a last resort, you could try backing up your x2 settings and then uninstalling x2 (use the remove settings option), and reinstalling. preferably without using "explorer replacement", and see if at complete default settings it works as expected.

Edit: Hmm... it would appear that I do also now have the "lack of refresh" as a residual side-effect of messing around with that option - before I used the key there was no problem with refreshing. I shall look further.

[Kilmatead]

Ok, I'd classify this lack of immediate drive-label change without refresh as being a bug (or at the very least a severe annoyance).

I restored multiple backup images, so it's not tied to this registry thing at all. It seems intermittent, but more often than not the "old name" (for lack of another description) is re-displayed after committing the rename, and yet upon forced refresh the new name appears as expected.

Obviously, it should not require this extra step. I don't think I noticed it before as I rarely edit drive-labels, but now that I'm looking for it, it appears rather often. Strangely, after a few extra renames, it will finally refresh for itself properly and continue to do so until I try it on another drive, at which point it requires a refresh again.

[Stefan]

I'm very sorry to hear that, Kilmatead!

The bug is hard to track down as windows explorer itself does not seem to be effected by this, it's just x2. I googled for the last 2 hours, but to no avail.

Maybe more luck tomorrow...

[Stefan]

I have to make an excuse as well. I persistet in saying that the drive letters are not part of the label, what is still true in respect of the hard drive volumes, however nikos was right concerning the mapped network folders. Didn't checked them as well.

I also learned something new: The leading drive letters in the drive menu can be used as hotkeys.

But this does not change the fact that those concluding drive letters in brackets shoudln't be there, right?