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
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.
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.
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
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.
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.