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

[Kilmatead]

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

The ones in the <Alt+F1> Drive Menu? Yes, that's normal - I don't know why he includes them as part of the label, but that's apparently just the way they are stored internally. For example, if you use the Drive Bar (toolbar), and hovered over a drive with the mouse, the tooltip (showing the label) includes the drive postfixed as everywhere else.

It's just a quirk. Think of it as a weird form of "stereo". (Sometimes you just have to accept the foibles of minutia, and accept that Nikos is too far away to conk on the head with a coconut to knock some sense into him.)

It's utterly daft that they are included as part of the editing-text when renaming, but that's just a pet-peeve...

[Stefan]

Think of it as a weird form of "stereo". (Sometimes you just have to accept the foibles of minutia, and accept that Nikos is too far away to conk on the head with a coconut to knock some sense into him.)

*rofl*

[nikos]

this is such an exceptional situation it is not worth two forum pages on it...
as there is no standard in labels, and x2 cannot know if a label exists or if it is pre/post-pended, and brackets are legal label characters, how do i tell if there is a drive letter in the label to remove?

next please!

[Kilmatead]

next please!

"Next" is the Drive-Label-Rename bug, oh Grand Poobah. I can easily turn that into 4 pages if that's what it takes for you to look into it.

[pj]

Oh forget all this drive label drivel already!!!!!

Let Nikos concentrate on IMPORTANT ISSUES -- you know like (*** FORUM HIJACK WARNING ***):

SAVING THE TAB HISTORY ON PROGRAM EXIT!!!!!!
(Yes K, I'm shouting again!)

As I'm working more and more on servers over very slow connections, walking a folder tree instead of jumping directly back to where I was yesterday takes an abysmally long time. Each folder load takes from 20 to 40 SECONDS each!

Please just push the tab history stack to the INI file or heap. When base machines have 8 to 16 GB RAM and 1 TERABYTE HDD's installed, megabytes JUST DON'T MATTER ANYMORE!!!!!

------------------------------
PJ in (wondering if hijacking EVERY forum would get Nikos' attention or just get me tossed) FL

[Stefan]

next please!

There are actually several unsolved next's in this thread, and I believe you may be in the happy situation to kill up to three of them with a single stone. Please read further.

x2 cannot know if a label exists or if it is pre/post-pended, and brackets are legal label characters, how do i tell if there is a drive letter in the label to remove?!

That's the point. As there shouldn't even exist a letter in the label in the first place. I don't know how x2 queries a drives label, but in case it receives/generates some mash-up like "PrivateStuff (D:)", it does it the wrong way. I'm dead sure there's a proper way to ask for and receive nothing but the label.

This very pure label would solve both the drive menu issue, and more important, the "dirty" default value when a drive becomes renamed in-place.

Now, I wonder if this couldn't be also the reason why the new name requires a manual refresh. Did you notice the fact that folders are renamed without issues AND get a proper refresh treatment, while drives have to deal with the interfering letter, and don't get refreshed? Coincidence...?
Maybe. But doesn't it appear like a case of failing assignment? It sounds logical to me that a drive won't refresh in case it's incorrectly addressed. Something like, "Hey, Label (D:), come forward!!" But nothing happens, as "Label" did not listen, since he wasn't mentioned.

This would also explain why the auto-refresh works in windows explorer. No interfering drive letter there, and voilà...

[Kilmatead]

I don't know how x2 queries a drives label, but in case it receives/generates some mash-up like "PrivateStuff (D:)", it does it the wrong way. I'm dead sure there's a proper way to ask for and receive nothing but the label.

Considering this is Windows we're talking about, there's no "proper way" to do anything - most users would be surprised at the spaghetti-code that just seems to self-generate the more you take a simple idea and expand it within the Win32API & COM.

That said, from the looks of things he seems to be just tapping into the literal string that Explorer itself uses when it displays the drives/labels, which leads me to think it's some COM detritus and he's just along for the ride.

Interestingly there is no single 'dedicated' function for reading a drive label, though there is one for writing them. Slightly more general functions exist in the API of course, such as GetVolumeInformationW (which will return a perfectly clean label amongst everything else), though these are (ironically) rather high-level since they take actual drive paths as arguments instead of more common lower-level things like GUID's/PIDLs, etc. I would be shocked (shocked, I say!) if Nikos actually used textual drive-paths under the hood, as that wouldn't make any sense.

[Stefan]

That said, from the looks of things he seems to be just tapping into the literal string that Explorer itself uses when it displays the drives/labels

Yes. This. Alienated second-hand junk.

I would be shocked (shocked, I say!) if Nikos actually used textual drive-paths under the hood, as that wouldn't make any sense.

Well, it absolutely does make sense assuming that x2 is actually not a file manager, but a downright fancy front-end for windows explorer.
But seriously: Rigged up data like this wouldn't make any sense not least because it will entail exactly those kind of troubles we are facing.

[Kilmatead]

Rigged up data like this wouldn't make any sense not least because it will entail exactly those kind of troubles we are facing.

Except (when you look at "the big picture" <© Nikos 1969> ), as far as the shell is concerned drive labels are completely superfluous information and only there for the amusement of the user. From MSDN itself, "A volume can have a label, a drive letter, both, or neither" which means it's a purely superficial property which is irrelevant to the underlying shell management activities.

In other words, that's why Nikos doesn't take them too seriously. From my own perspective, I don't use them that much ("set and forget"), like mount-point link names... they are nothing but a quick reference. Granted, while I don't share your apparent dislike of CLSID's (I've gotten so used to the control-panel shortcuts that I can recite many from memory), if I was stuck drilling into GUID paths for drives ("\\?\Volume{26a21bda-a627-11d7-9931-806e6f6e6963}\") all day, even I'd go a little stir-crazy. (Which is probably why I found the idea of explorer having an option to disable drive-letters as being downright crazy, and rather wonder who would even use such a thing.)

[nikos]

how many angels can dance on a pin of a needle?

[Stefan]

Just a s much as the devil holds slot machines in hell.

How many symptoms are needed until one bug gets fixed?