Not quite.
(Thats what often happens but) in this case, if Windows and Mac work differently, then there is a Xojo bug of some kind.
However, I dont see the potential bug as an issue.
Even if they did work the same, I see the real issue as the way the file is being tested.
To me, its bad practice to go straight for the file at the bottom of the tree like this:
f = SpecialFolder.Desktop.child("test").child("test.zip")
If there is a need to look in the folder SpecialFolder.Desktop.child(“test”) then you should set that as a variable and know that it exists, before looking inside it for stuff.
is just asking for trouble.
A nil return tells you very little about the problem.
Any error trapping MUST work through the levels one by one to find out what went wrong anyway.
So do it right from the start.
[code]Dim f as folderitem
dim mysubfolder as folderitem
if specialfolder.desktop.exists then // this should work, but hey, just in case…
mysubfolder = SpecialFolder.Desktop.child(“test”)
if mysubfolder <> nil and mysubfolder.exists then
f = mysubfolder.child(“test.zip”)
if f <> nil and f.exists then
Indeed, the LR states that [quote]Returns Nil only when some portion of the path to the child does not exist.[/quote]
The fact that it does not work on Windows and works on Mac may very well be considered a bug (Christoph, why did you not file a report ?). Yet, Jeff is right. It is bad practice to assume an entire folder branch exists without testing each member.
At the risk of repeating myself, workarounds are the essence of programming. Bumping again and again into a problem and expecting different results while ranting in forum is irrational at best. Even if the LR says this or that, when one sees a different behavior, file a bug report, simply work around the issue, and move on. That is also called coding defensively.
In spite of Xojo’s tremendous efforts, slight discrepancies between platforms are to be expected, would they be due to very real framework differences, or changes in the system. Now that Microsoft, like Apple, has a new issue every year, this kind of thing may yet happen more often.
Dim f As FolderItem = SpecialFolder.Desktop.Child(“test”).Child(“test”).Child(“test.zip”)[/quote]
Thank you Eli for thinking clear. You do understand my point.
@Greg O’Lone
Can you answer Eli’s question?
To answer your questions:
No and it correctly returns nil and NOT an exception.
No and it correctly returns nil and NOT an exception.
No and it correctly returns nil and gives an exception. Why does it only gives an exception for this and not the previous?
And to be clear, it can be done for folders and/or files. This always triggers the issue.
[quote=326360:@Christoph De Vocht]This does throws an exception:
dim f as FolderItem
f = SpecialFolder.Desktop.child(“test”).child(“test”).child(“test.zip”)
[/quote]
As it should.
SpecialFolder.Desktop returns a valid, existing folder
.child(“test”) returns a valid, non-existing folder
.child(“test”) - the second one - returns Nil
.child(“test.zip”) tries to reference Nil and throws an exception
[quote=326461:@Tim Hare]As it should.
SpecialFolder.Desktop returns a valid, existing folder
.child(“test”) returns a valid, non-existing folder
.child(“test”) - the second one - returns Nil
.child(“test.zip”) tries to reference Nil and throws an exception[/quote]
Right, that’s expected behavior. But that the original example by Christoph does that, and only on Win, is what’s a bit strange, provided that “SpecialFolder.Desktop returns a valid, existing folder”.
f = SpecialFolder.Desktop.child("test").child("test.zip")
does not cause a nil object exception on either[/quote]
Thanks for testing, Norman.
Then only Christoph can explain what’s going on on his system where it behaves differently. Until then, I guess we can assume there is no bug.
