XYplorer Beta Club

It's a trick that some may know and some don't, but it's possible to create folders based on GUIDs. For example, call a folder the name that's code below and you get a folder that's a fully working Recycle Bin (you can even DnD to it, unlike with XY's RB ): Unfortunately, XY seems to struggle with display of icons for such a folder (created in either special/non-special folders). List needs a manual refresh to show the correct icon and the Tree refuses to show it completely (just shows the standard folder icon). Something fishy here?

Crass! You got any documentation this?

I get no struggle with display of icons, but other issues. ATM I would not recommend using such folder names...

In the way of documentation, I know that all GUIDs are located in "HKEY_CLASSES_ROOT\CLSID" of the Registry and each CLSID contains all the necessary information pertaining to that GUID. The appropriate value is passed to the Shell, it does the searching and voila!

This is what Wikipedia says And here's a MSDN article http://msdn.microsoft.com/en-us/library ... 85%29.aspx Some more info here too: http://social.msdn.microsoft.com/Search ... Query=GUID

What seem to be the difficulties that you're encountering?

Thanks for the info but I know what a GUID is. I just never heard that one can simply append it to the name and by this way change the nature of a folder. This is crass.

zer0 wrote:What seem to be the difficulties that you're encountering?

Dragging an item that's inside such folder lead to a crash. I fixed that.

admin wrote:Crass! You got any documentation this?

Using a CLSID as a file extension is briefly described (actually it's almost just an off-the-cuff mention) in this MSDN/MSJ article about shell namespace extensions (http://www.microsoft.com/msj/archive/S332.aspx):

Yet another alternative is to use the CLSID of your name space extension as the file extension of a folder. If you wanted to create a folder called Cheese that was really the junction point of a name space extension, you would actually create a folder named "Cheese.{CLSID}".

The article is probably well worth a read.

admin wrote:I just never heard that one can simply append it to the name and by this way change the nature of a folder. This is crass.

I don't think it's crass at all. Since the structure of such a folder is "Name.{GUID}", it's not that different from files that have a base name and an extension. Shell [almost] doesn't care about the name, it cares about the extension and what it does with a file when it's double-clicked/right-clicked on varies according to its extension.

Same story with GUIDs. This means that folders like "My Computer", "Recycle Bin", "Libraries" (in Win 7, but hopefully soon XY too ) that are in the Tree are same as manually created folders, except they are presented in a "prettier" way. "My Computer" is shown as "My Computer" rather than "My Computer.{20D04FE0-3AEA-1069-A2D8-08002B30309D}", yet both are identical in their function.

Incidentally, I found the following VB6 code snippet that allows opening of such special Explorer windows: http://www.nirsoft.net/vb/openexpl.html

EDIT: And some more bed-time reading for you: http://msdn.microsoft.com/en-us/library ... px#virtual

It appears as if these GUID extensions are only half-heartly implemented by MS. I can bypass them using Kernel API as well as Shell API. For example I can move files into such a folder without any problem, and WE cannot see them. They are hidden from any file manager that treats folders with GUID extensions as WE does (which is every file manager apart from XY AFAIK). Even WE itself is undecided: it shows the GUID extension in the address bar but hides it in the tree.

I decided to keep the "raw approach" (as known from XY's raw recycle bin) here, in other words do nothing apart from fixing crash bugs related to these beasts (which I've already done).

admin wrote:It appears as if these GUID extensions are only half-heartly implemented by MS. I can bypass them using Kernel API as well as Shell API. For example I can move files into such a folder without any problem, and WE cannot see them. They are hidden from any file manager that treats folders with GUID extensions as WE does (which is every file manager apart from XY AFAIK). Even WE itself is undecided: it shows the GUID extension in the address bar but hides it in the tree.

I decided to keep the "raw approach" (as known from XY's raw recycle bin) here, in other words do nothing apart from fixing crash bugs related to these beasts (which I've already done).

I'm not sure I agree.

The reason why GUID's implementation in Explorer may be a half-hearted one because this feature isn't a user feature, it's a developer feature. Interestingly, the way it looks on my XP system is that GUID extension is hidden in AB, but shown in the Tree -- a mirror reflection of what you see.

However, just think of the potential. Remember those Web folders that I mentioned that I can't see in the Tree? Remember people asking why isn't their smartphone showing in XY's tree? A decent implementation and those people would be as happy as a fat kid in McDonald's . It'd also mean that people would be able to add system-related items to their Tree (esp. MiniTree) without additional intervention from you. A competing navigational manager has already implemented the full extent of items possible in the Tree -- this is a chance to draw level.

I have a feeling that this thread is turning into a wish thread and that was not my intention. Explorer and another major file manager provide functionality for GUID folders. Their implementation may be patchy in places, but it's there. XY can take that and improve. At the end of the day, they are folders that are part of the file system.

P.S. In .0009 GUID folders don't lead anywhere. Double-click has no effect, there are no child folders.

Conc. smartphone in the tree: if that's another GUID folder, cool, but no idea where to find what GUID that is. Well, now that I think about it it might well be subfolder of Desktop... worth a check...

zer0 wrote:P.S. In .0009 GUID folders don't lead anywhere. Double-click has no effect, there are no child folders.

Might depend on the GUID. Recycle Bin GUID works fine here.

I know that all GUIDs are stored in HKCR\CLSID with the default value for each particular key being the descriptor.

Regarding GUID folders not working, may well depend on a particular GUID. However, Recycle Bin isn't working here as per screenshot below: XY GUID folder appears empty, whereas System RB contains the deleted item.

Kind of OT but somewhat relevent. I thought this was interesting.

http://www.osnews.com/story/22691/Activ ... n_God_Mode_

jayfischer wrote:Kind of OT but somewhat relevent. I thought this was interesting.

http://www.osnews.com/story/22691/Activ ... n_God_Mode_

Inspiring!

admin wrote:Recycle Bin GUID works fine here.

A further bug has been identified -- context menu shows "Empty Recycle Bin" greyed-out, even though item(s) is/are present in it.

zer0 wrote:

admin wrote:Recycle Bin GUID works fine here.

A further bug has been identified -- context menu shows "Empty Recycle Bin" greyed-out, even though item(s) is/are present in it.

Again, this works fine here. But as I said, I won't dig into this now. I'll happily send users that insist in working with GUID extension folders to other file managers.