How do I specificy a location using GetFolderItem?

General
1

I have an sqlite database in SpecialFolder.UserHome.Child(".test.db") that I need to open. I thought I could use the following line to reference it:

[code]Dim dbFile as FolderItem
Dim db as SqliteDatabase

db.dbFile = GetFolderItem(SpecialFolder.UserHome.Child(".test.db"))[/code]

Unfortunately, this isn’t right. I get an error that says the ‘path’ expects a string but got a folderitem. I understand the error but how do I fix it? I’ve been through the doc but can’t seem to find any solution. Am I missing something simple? What am I doing wrong?

Thanks!
Dave

2

No need for getfolderitem at all

db.dbFile = SpecialFolder.UserHome.Child(".test.db")

3

Thank you Norman. Simple enough!

4

Is there a reason for the extra “.”?
Normally CHILD does not require it, unless (under OSX) its a hidden file

5

[quote=272567:@Dave S]Is there a reason for the extra “.”?
Normally CHILD does not require it, unless (under OSX) its a hidden file[/quote]

Basically for Ubuntu and MacOS. Ubuntu wants (or used to want) config files in .config directory under the users home directory. Since it also works on MacOS, I just kept the convention for both.

6

yes it works, and the reason is to HIDE the file from view… something that you may want to do with a config file, but may NOT want to do with a database file…

[quote]In Unix-like operating systems, any file or folder that starts with a dot character (for example, /home/user/.config), commonly called a dot file or dotfile, is to be treated as hidden – that is, the ls command does not display them unless the -a flag (ls -a) is used. In most command-line shells, wildcards will not match files whose names start with . unless the wildcard itself starts with an explicit . (although this is sometimes configurable; for example, the dotglob[5] option in bash).

The notion that filenames preceded by a . should be hidden in Unix was probably an unintended consequence of trying to make ls not show . and …[6]

A convention arose of using dotfile in the user’s home directory to store per-user configuration or informational text. Early uses of this were the well-known dotfiles .profile, .login, and .cshrc, which are configuration files for the Bourne shell and C shell and shells compatible with them, and .plan and .project, both used by the finger and name commands.[7] Many applications, from bash to desktop environments such as GNOME now store their per-user configuration this way, but the Unix/Linux freedesktop.org XDG Base Directory Specification aims to migrate user config files from dotfiles in $HOME to non-hidden files in $HOME/.config[8] - a hidden directory.[/quote]

[quote]Mac OS X
In addition to the “dotfile” behaviour, files with the “Invisible” attribute are hidden in Finder, although not in ls. The “Invisible” attribute can be set or cleared using the SetFile command; for example, invoking SetFile -a V jimbo will hide the file “jimbo”.[10] Starting in Mac OS X Snow Leopard, the chflags command can also be used; for example, chflags hidden jimbo will hide the file “jimbo”.[11][/quote]

not to mention it MAY cause errors in you cross compile to Windows at some point

7

You should keep your application data in a subfolder within ~/Library/Application Support. Ideally if you’re using NSUserDefaults then your preferences would get set in the proper location, but it’s not required at this time.

Please do not add another dotfile to the user home folder, on Mac this is just a mess. A lot of crappy open source projects do it for the very same reason you mentioned and it makes my heart stop when I have to find an invisible file.