locked
What is best practice to check if a picked folder is a "Library" folder?

    Question

  • Since I try to rebuild the functionality of Directory.CreateFolder that takes a full path an creates all missing subfolders along the desired hirachy, I came accross the need to distinguish if the starting folder (picked via FolderPicker) is a "normal" folder or a "Library" Folder since "Library" folders tend to return an empty path, thus demanding for special treatment in my code.

    So what is best practice to check if a given StorageFolder is a "Library" folder?

    I could do

    if (folder.DisplayType == "Library")
    {
      DoSomething(folder);
    }

    but then the question arises, will DisplayType always return "Library" even on non English Windows? Since DisplayType should return the "user-friendly" type, users might expect it to be friendly in their own language, thus braking my logic.

    Otherwise if I can rely on always getting back "Library" how friendly will a user find it when applications don't care about their prefered language, since MS didn't provide a really friendly DisplayType method ;-)

    Or do have developers to add the friendlyness to the app?

    Investigating this matter in the online help to DisplayType did not help, since this issue is not addressed in the barely helpful "one-line"  help.

    I think MS has to put a lot more effort into building a useful help for Windows Store App framework functions. That would maybe reduce time wasted for users/developers to investigate and then still having to ask questions in forums like this and MS experts having to answer basic/fundamental questions.

    Tuesday, January 8, 2013 10:40 AM

Answers

  • Hi Scruff,

    Your problem is that you are trying to solve the problem (hierarchical structure of folders holding files) by addressing a subset of it (file system objects). This fails when you look at the overall picture.

    The important point is that StorageItems are the canonical storage objects for Windows Store apps. File system objects are an implementation detail of a subset of the StorageItem hierarchy. It is impossible to map the entire StorageItem hierarchy with file system paths, and there is no good reason to give your app an artificial limitation by doing so.

    If you slightly alter your solution to create hierarchies relative to a StorageItem then it will work for all cases, including libraries and app initiated locations. Since you need to root your path at an accessible StorageFolder (such as a KnownFolder or one chosen by the user via the FolderPicker) in order to have access to make the change this doesn't add any significant limitation, only benefits.

    So to your immediate question: No, there isn't a better way; however, what you are doing will only work in limited scenarios.
    But the correct answer is: Don't do that. Use the StorageFolder as a StorageFolder. There is no need to convert it to the path.

    --Rob

     


    Friday, January 11, 2013 12:22 AM
    Owner

All replies

  • DisplayType is intended to be displayed to the user, so it will be localized to the language they are using.

    The problem you are running into is rooted in relying on paths. The best practice is not to depend on paths but to use StorageItems natively. Not all StorageItems refer to file system locations and trying to coerce them to do so will limit your app. You should root your "full path" to the StorageFolder and not to a file system path.

    See my blog Skip the path: stick to the StorageFile for more commentary on this.

    --Rob

    Tuesday, January 8, 2013 8:11 PM
    Owner
  • Thanks Rob,

    but in my special case - and I think a lot of business users are still thinking that way - I need a hirachical structur of folders holding files.

    So when my program should be able to create this folder structure on the basis of some business logic and place files in their respective folders, I will ultimately have to deal with full paths at some point.

    Given this and the fact, that I prefere being overly cautious when dealing with user input (e.g. picked starting point for the hirachy or manually altered path) I thought I need to distinguish between a "normal" full path (which I normally get back from a FolderPicker) or a KnownFolder (which I get, when the user decides to drictly pick one of Music/Videos/Documents/...).

    Thus my question.

    So even if I'd normally go via the StorageFolder, how should I do the other, if I need to?

    At the Moment I'm doing this:

    if (folder.Path.Length > 0)
      DoSomethingWithFullPath(folder);
    else
      DoSomethingWithSpecialFolder(folder);

    My question was NOT "Should this be done, at all?", but is there a better way than this?

    Thursday, January 10, 2013 10:24 AM
  • Hi Scruff,

    Your problem is that you are trying to solve the problem (hierarchical structure of folders holding files) by addressing a subset of it (file system objects). This fails when you look at the overall picture.

    The important point is that StorageItems are the canonical storage objects for Windows Store apps. File system objects are an implementation detail of a subset of the StorageItem hierarchy. It is impossible to map the entire StorageItem hierarchy with file system paths, and there is no good reason to give your app an artificial limitation by doing so.

    If you slightly alter your solution to create hierarchies relative to a StorageItem then it will work for all cases, including libraries and app initiated locations. Since you need to root your path at an accessible StorageFolder (such as a KnownFolder or one chosen by the user via the FolderPicker) in order to have access to make the change this doesn't add any significant limitation, only benefits.

    So to your immediate question: No, there isn't a better way; however, what you are doing will only work in limited scenarios.
    But the correct answer is: Don't do that. Use the StorageFolder as a StorageFolder. There is no need to convert it to the path.

    --Rob

     


    Friday, January 11, 2013 12:22 AM
    Owner
  • Thanks Rob,

    I'll keep this in mind and try to keep my hierachical folder structur relative to any given StorageItem, but since users tend to have their own minds, I'd need a way to translate a possibly absolute path passed into my app into a relative one.

    But when you say my approach to achieve the distinction between StorageItems having a full path and others not having such is acceptable, I'm happy.

    Thanks again.

    Friday, January 11, 2013 11:05 AM