SpecialFolder.Documents is Nil on Windows 10

I’ve had a handful of Windows 10 users failing to be able to run my app recently.

Isolating the code, it looks like the Documents folder does not exist. This simple code fails.

dim f as FolderItem f = SpecialFolder.Documents // F = nil

The users are other able to write from other apps like MS-Word to their documents folder. I don’t believe there’s anything special about these machines like documents folders on a network or anything.

Any ideas?

I would try

dim f as FolderItem f = SpecialFolder.UserHome f = f.child("Documents")

It is also possible that opening silently the documents folder is not possible because of administrative privileges.

I have several hundred customers known to be using Windows 10
My app begins by creating folders and files in Specialfolder.documents

I have no reports of this failing at all.

The likelihood here is that the specific machines reporting an error are dumb machines, eg machines where the Documents folder is a network alias of some kind.
Often they have no accessible C: drive either.

Maybe
https://www.eightforums.com/general-support/50801-my-documents-folder-location-not-available.html

As a matter of principle, I never work directly on user documents. I always keep all data inside a SpecialFolder.ApplicationData subfolder, and provide Open and Save As for users to load and save their files. That saves me a considerable amount of pain.

[quote=317317:@Stephen Dodd]I’ve had a handful of Windows 10 users failing to be able to run my app recently.

Isolating the code, it looks like the Documents folder does not exist. This simple code fails.

dim f as FolderItem f = SpecialFolder.Documents // F = nil

The users are other able to write from other apps like MS-Word to their documents folder. I don’t believe there’s anything special about these machines like documents folders on a network or anything.

Any ideas?[/quote]

Since your code fail there, the users may have a problem with their own user-specific Documents. Maybe the users are writing to the Public Documents (SpecialFolder.SharedDocuments). Perhaps check for .Documents and if unavailable then offer them .SharedDocuments instead. Then you don’t have to help them trouble shoot their computer problem.

The problem with .ApplcationData is that by default, Windows hide it in the Windows Explorer. So if users want to copy files manually they won’t be able to find them unless they are savvy enough to unhide it.

Precisely, they cannot ruin the data.

Providing them save and open options, like do Office and all standard apps, lets them modify them at will without risk.