Say you want your FileÂSaveÂPicker to default to the same folder that was picked by the FolderÂPicker. Or your FileÂOpenÂPicker to default to the same directory that was used by the FileSavePicker. Or any combination of the above. Basically, you want all the pickers to resume where the previous one left off. How do you do that?
By default, each picker keeps a separate history of recent locations, but you can override this by setting an explicit SettingsÂIdentifier on the picker. We saw this earlier when we explored how to keep two different sets of history, so that you could have a most recent location for, say, movie clips, and a different most recent location for background music.
But in addition to keeping settings separate, you can use the SettingsÂIdentifier to make them the same.
If you give your FileÂSaveÂPicker, FileÂOpenÂPicker, and FolderÂPicker the same SettingsÂIdentifier, then they will share the same history of recent locations. Each one will resume in the location that the previous one left off.
async Task<StorageFile> LoadAsync()
{
var picker = new FileOpenPicker {
SuggestedStartLocation = PickerLocationId.DocumentsLibrary,
FileTypeFilter = { ".txt" },
SettingsIdentifier = "Common"
};
return await picker.PickSingleFileAsync();
}
async Task<StorageFile> SaveAsync()
{
var picker = new FileSavePicker {
SuggestedStartLocation = PickerLocationId.DocumentsLibrary,
FileTypeChoices = { ["Plain Text"] = new[] { ".txt" } },
SuggestedFileName = "New Document",
SettingsIdentifier = "Common"
};
return await picker.PickSaveFileAsync();
}
async Task<StorageFolder> PickFolderAsync()
{
var picker = new FolderPicker {
SuggestedStartLocation = PickerLocationId.VideosLibrary,
FileTypeFilter = { ".txt" },
SettingsIdentifier = "Common"
};
return await picker.PickSingleFolderAsync();
}
You can combine this with the previous trick of keeping different pickers separate: You can have a group of pickers that all share their settings for movie clips, and another group of pickers that share their settings for background music.
Bonus chatter: The Win32 equivalent of the Windows Runtime SettingsIdentifier is IFileDialog::SetClientGuid. Call IFileDialog::ClearClientData to clean up the saved information.
In my experience it’s better on desktop to just manually save the absolute path/PIDL than to use IFileDialog::SetClientGuid() which routinely forgets my settings after a few days.
Why are explorer thumbnails limited to a maximum of 256×256 pixels? There is registry value but increasing it doesn’t help. With 300% DPI, the font scaled a lot but the images aren’t so there is a lot of empty space in Windows Explorer between the items.
Why the limit? Why not just let it be as big as someone want it to be? That’s another Windows mystery to solve…
Because that was huge when these sizes were introduced in Windows Vista when 1280×800 was a common screen resolution? I wonder if icons are even properly handled if one would allow bigger sizes, centering them like smaller icons which do not provide bigger resolutions…
I’d be happy with 256×256 if I could get the W10 thumbnail service to stop locking up on .MKV files. When this happens on my PC, all shell context menus deadlock on creation until the offending dllhost process is terminated. A normal user would be forced to reboot.