Network drives
-
I realized the sad fact, that there's no FolderTreeView control on .NET, just a dialog, so I've created my own based on browsing capabilities of the TreeView. It works fine despite fact there are no such beautiful icons like in explorer and root nodes are drives, not the Desktop... It's OK, but now I'm looking for a way how to deal with network drives, shared folders etc. In Explorer, there's just some "Network Neighborhood", but I'm using ManagementObjectCollection to obtain logical drives. What do I need to enlist network drives such as shared folders? Thanks in advance.
-
I realized the sad fact, that there's no FolderTreeView control on .NET, just a dialog, so I've created my own based on browsing capabilities of the TreeView. It works fine despite fact there are no such beautiful icons like in explorer and root nodes are drives, not the Desktop... It's OK, but now I'm looking for a way how to deal with network drives, shared folders etc. In Explorer, there's just some "Network Neighborhood", but I'm using ManagementObjectCollection to obtain logical drives. What do I need to enlist network drives such as shared folders? Thanks in advance.
Enumerating shell namespaces (which is actually what they're called; some namespaces just happen to be drives while others are mapped drives, etc.) includes a lot of complicated calls (relatively speaking). There's no simple solution to what you want to do. To do this correctly WMI isn't the best solution. Instead you need to use the Shell interfaces which return you namespaces and allow you to query for their icons along with many other things. Doing this doesn't work with paths at all, but item ID lists (IDLs) of objects. Folders and files have unique IDs. The control panel has a unique ID, etc. Everything visible in the shell namespace has a unique ID. See Navigating the Namespace[^] for an overview with links and a sample in native code. Another problem is that since all these interfaces are native you'll need to create RCWs (runtime-callable wrappers) for several dozen interfaces, define lots of constants (you'll need the C/C++ headers in the Platform SDK[^] - also installed with Visual C++ - for values), and define lots and lots of structures - some of which aren't so easy because of unions which don't have an equivalent representation in .NET. Because of this you might consider writing such a control in Managed C++ - which allows you access to native constructs but compiled to managed code (the resulting assembly is actually a mix of native and managed code, which means the assembly isn't verifiable and won't run in some security contexts like from an Internet or intranet site). The article http://www.codeproject.com/csharp/csdoesshell1.asp[^] on this site will give you a start. You can find other articles about shell namespace extensions in the search results at http://www.co