Parent.Child ?

I’m having difficulty understanding opening a file.

This work ok, but I would prefer to use a relative path than an absolute path.

[code] dim mDBName as string
mDBName = “Macintosh HD:Users:jim:Development:Xojo:” _

  • “Xojo My Projects:!My Desktop Projects:” _
  • “RVC User Project:Databases:user.db”

dim f as new FolderItem(mDBName)[/code]

I have tried these (and many other ways) and just can not get it to work.

f = GetFolderItem(“Databases/user.db”)

f = App.ExecutableFile.Parent.Child(“Databases”).Child(“user.db”)[/code]

My project code is in the “RVC User Project” folder, along with the “Databases” foldeer which contain the file I’m trying to open.

Help would be appreciated.

Get used to creating a folder named for your app, in the ApplicationData folder (or maybe Documents)

On app startup, check the folder exists
If not, create it
When it exists, check the db exists inside it
If not, create a new one, (or maybe unzip a populated one you include in the app bundle)

That way, your debug app doesnt need to work out where it lives, and isn’t trying to update a db which is local to the app.
(windows doesnt allow that and Mac doesnt like it)


[code]dim f as folderitem
f = specialfolder.applicationdata.child(“myappname”)
if not f.exists then f.createasfolder
f = f.child(“theddb.db”)
if not f.exists then
//create or unzip
end if

//open the db now… f has the folderitem[/code]

it depends on the operating system

on Mac (if I remember correctly)


But ApplicationData Folder is the better choice

+1 …although if you are going to produce code to run on Windows, My Documents can be moved to a non-local server and will not be available if they are disconnected from the network. We used to see this a few times a year with users on Laptop that are on the road and didn’t have access to their network. Use ApplicationData as Jeff said, it will save you headaches down the road.

And pick up TPSF for accessing in-app resources. It uses declares on Mac to be sure you’re doing it right, and handles the different possibilities of folder names on Windows. Plus it offers easy cross platform access to an Application Data folder for your app, so you don’t have to find it yourself.

In general, it makes a lot of things as easy as one line.

If you ever have any intention to sell this app on the MAS, you better follow Jeff’s advice and place the database file in your own folder with ApplicationData.

Place the database file in Resources, then copy it to ApplicationData on first run like so (Using Tim Parnell’s TPSF) :

dim f as folderitem f = specialfolder.applicationdata.child("myappname") if not f.exists then f.createasfolder f = f.child("theddb.db") if not f.exists then //create or unzip dim mydatabase as folderItem = TPSF.Resources.child("theddb.db") mydatabase.Copyfileto(f) end if //Use f as before.

What you are doing right now would not pass Apple’s reviewer.

This app I’m working on is NOT a commercial product. Will more than likely never “Build” an object, just run as debugger,

Still can’t get it to work.

commercial or not, you should still follow advice like Michel provided.
Use of “specialfolder” and “child” will solve 99% of of your issues if used properly.

Are you having the problem using the debugger, running standalone application, or both?

Did you look at what Axel wrote? , I have to access an HMTL help file out of the bundle this way on the Mac.

following reccomended procedures, this would never be part of the issue

…covers a lot of ground. What are you seeing there, is throwing an exception or are you getting a database error?

Although I agree with you, I am not one to tell someone else how to do their job. I’ve been on the other side of the fence where I can’t follow the “recommended” procedure (for one reason or another). Just offering some additional suggestions in case this is one of those cases.

Sorry… I totally disagree… If there is a method that is reccommended, and you don’t (or refuse) to attempt it, then you are saying “Nah, I don’t really want your help, because I want my broken way to work”… and in those situations, I move on, so as to not waste my time. Doing it the “right” way it will work both in the debugger and compiled.

I don’t think Jim is saying anything like that. There are times when just getting an answer quickly to a research problem is a lot more important than doing it “the right way”. The first time I dove into the Application Support folder, it took a bit of experimenting and work to get it working right, maybe Jim doesn’t have the time at the moment. I think it is worth taking the time to see how it works, but my situation is likely different than his.

My disagreement was with Langue :slight_smile:

Jim, running in the debugger is all the more reason to put the database in a fixed location outside the app. It will save you having to copy the file all the time and allow you to save the data from one run of the app to the next.

[quote]This app I’m working on is NOT a commercial product. Will more than likely never “Build” an object, just run as debugger,
Still can’t get it to work.[/quote]

Put your database in Documents. Easy.

Change your code to this:

dim mDBName as string dim f as FolderItem f = Specialfolder.Documents.child("user.db")

Thank Tim and all the others who replied.

The solution to my original question is

dbf = App.ExecutableFile.Parent.Parent.Parent.Parent.Child("Databases").Child("user.db")
However I’m going to put the db in a common location outside of the project folder.

This line of code help me to figure out just what the solution was:

s = App.ExecutableFile.Parent.Parent.Parent.Parent.Name[/quote]

Thanks again.

Its different on Windows and Macs.
SpecialFolder isnt.