views:

20

answers:

1

I am trying to implement a filesystem browser using the WindowsAPICodePack for C# (.Net 4), and it works pretty well, except that the ShellObject system treats zip files as folders, whereas I'd prefer they be files. Is there some way I can force it to work this way? The low-level interop it does is beyond me.

As far as I can tell, internally it asks if the item is a Folder or a Filesystem element. It then uses this (and some type checks) to figure out what it actually is. Is it safe to force it to treat it as a file if it's Compressed? Or do I have to do something else?

+1  A: 

Ok, well first, I saw that there was a flag in ShellNativeMethods.SFGAO called SFGAO_COMPRESSED. This doesn't seem to actually appear ever though, maybe it was deprecated?

Failing that, I eventually just cheated and did the following in ShellObjectFactory.cs:

Below:

// Is this item a Folder?
bool isFolder = (sfgao & ShellNativeMethods.SFGAO.SFGAO_FOLDER) != 0;

I added:

// Is this a compressed Folder?
bool isCompressedFolder = (itemType == ".zip");

And then I replaced

else if (isFolder)

with

else if (isFolder && !isCompressedFolder)

This is a total hack, but it seems to work, so unless someone has a better idea I'm sticking with this. Hopefully it'll help someone else out in the future, posts on the WindowsAPICodePack seem pretty rare.

JustABill
So what happens with .rar's and .7z's?
GONeale
Windows can't natively open those like it can with .zip, so it's thankfully not a problem.
JustABill
I'm absolutely struggling with the same problem as you, I am testing SFGAO.COMPRESSED as 0x04000000 and somewhere else I read as 0x80, both always return zero :( This is incredible they both don't work, it's a standard Windows API interface, there must be something we are overlooking. :(
GONeale
It's been months since I tried this, but as I recall I pulled my hair out for days before giving up and just doing the horrible ".zip" hack shown above (didn't post the question until after I'd been stumped for a while). There's depressingly little documentation on the WindowsAPICodePack. The official documentation on SFGAO says it's 0x04000000 - http://msdn.microsoft.com/en-us/library/bb762589.aspx
JustABill