folderitem/Volume bug?

Example from documentation.

This doesn’t work, gets a nil exception:

Dim f as FolderItem
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”).Child(“OFFICE11”).Child(“WINWORD.EXE”)

This works :

Dim f as FolderItem
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”). Child(“OFFICE11”)

thanks.

Well whats the full path to WinWord.exe ?
IF its not \Program Files\Microsoft Office\OFFICE11\WINWORD.EXE
where boot drive is whatever drive you booted the machine from

IF one of the dirs along that path doesn’t exist (like Office11) then you would get a nil object exception from the example but its meant to be an illustrative example

If you try

Dim f as FolderItem
f= Volume(0).Child("Program Files").Child("Microsoft Office"). Child("OFFICE11")
break

when the debugger stops on the break statement then click on F in the debugger variables pane & see if EXISTS = true
I’m guessing its not

Folderitems CAN refer to non-existing dirs or files BUT when constructed using a path like the example does ALL dirs along the way have to exist as well

more than 3 .Childs will blow it up

Reread what Norman said. You can have many more that 3 .childs, that is not the issue here, the problem is that one of the directories probably does not exist.

f= GetFolderItem(volname).Child(“Users”).Child(“Public”).Child(“Games”).Child(“test”)

same thing here, so, how do i test a path/file exists before i try and open it and get a nil exception

Test each folder along the way separately.

f = volume(0).child(“Users”)
if f.exists then f = f.child(“Public”)
if f.exists then f = f.child(“Games”)
if f.exists then f = f.child(“test”)

I guess what doesn’t make sense in the example I posted :

This doesn’t work, gets a nil exception:

Dim f as FolderItem
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”).Child(“OFFICE11”).Child(“WINWORD.EXE”)

This works :

Dim f as FolderItem
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”). Child(“OFFICE11”)

I don’t have office on this machine, so none of those directories exist except Program Files.

[quote=67789:@Ralph Hargis]This works :

Dim f as FolderItem
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”). Child(“OFFICE11”)[/quote]
That means that .Child("OFFICE11") yields NIL, which is consistent with what you’re reporting.

f= Volume(0).Child(“Program Files”) --> valid folderitem that exists.
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”) --> valid folderitem that does not exist
f= Volume(0).Child(“Program Files”).Child(“Microsoft Office”). Child(“OFFICE11”) --> NIL, an impossible situation (you can’t refer to a file/folder in a folder that doesn’t exist.)
One more .Child and you get a NilObjectException.

Tims bang on

something like this “for example” code (to illustrate how to test each step of the path not “hey drop this in your production app” kind of code)

Dim f as FolderItem f= Volume(0) if f <> nil and f.exists then f = f.Child("Program Files") if f <> nil and f.exists then f = f.Child("Microsoft 54Office") if f <> nil and f.exists then f = f.Child("OFFICE61") if f <> nil and f.exists then f = f.Child("WINWORD.EXE") end if end if end if end if

tests each step and stops trying to go deeper in the hierarchy where things don’t exist or are nil

Thanks Tim and Norman for your courteous replies.

Doc’s don’t really give you any indication of the possibility of a nil exception, one would assume if it doesn’t exist, it would return nil.

But then you’d never be able to create a file. You need to be able to create a folderitem that refers to a file that doesn’t exist yet, so you can create it. But if you try to use that non-existent file to create a child folderitem, you get an error. The newer Xojo api’s would throw an exception in that case, but the older api (such as FolderItem) return NIL on error.

[quote=67808:@Ralph Hargis]Thanks Tim and Norman for your courteous replies.

Doc’s don’t really give you any indication of the possibility of a nil exception, one would assume if it doesn’t exist, it would return nil.[/quote]

As you can see here, the documentation states the behavior you’re encoutering perfect.

Actually, that page implies that the entire line will gracefully return nil, not that some intermediate step will return nil, causing the rest of it to throw an exception. It could be more clear in that regard.