MAJOR BUG in R2 that needs a fix asap

Targets macOS
1

I encountered a massive new bug that will break a lot of projects for sure.

Do this when running Xojo 2026R2 (works with all previous Xojo versions down to v1.00

var f as FolderItem

f = SpecialFolder.Desktop

if f.child(“test”).Exists = false then
f.child(“test”).CreateAsFolder
end

When the folder ‘test’‘ does not exists, it should create the ‘test’ folder.

But it fails at if f.child(“test”).Exists = false then

In any case, it always returns true.

Incredible that this passes the beta. Wow …

FWW macOS26

2

This works perfectly for me on 26.5.1 (ARM). In fact, I have this sort of code all over the project I’m currently focused on and it worked through all of the betas.

3

No problems here Mac Intel 15.7.7

4

You did compile with Xojo 2026R2?

And it creates a ‘test” folder on the desktop?

I tried this several times, but when there is no ‘test’ folder on the desktop, it does not create the folder. .exists always returns True.

I am running macOS26.5.1

EDIT: I tested it on my two system (both ARM) and it always return true (even when the folder item does not exists. Very odd.

5

Yes. As I said, I do this a lot. If it were a universal bug, I’d have found it immediately when it was introduced.

6

Me too, but here it doesn’t work anymore. Always return true.

Extremely odd.

FWW When I revert back to Xojo2026R1.2 it works fine.

7

Working here on 26.5.2 M2 Xojo 2026r2

8

I think it is related to this:

  • macOS: Fixed the use of chained Child methods over a valid FolderItem on macOS; so its behavior adheres what is described in the documentation and also matches the current behavior of Windows and Linux. Now, if some of the intermediate Child calls for the path chain doesn’t exist, it returns Nil. (81294
var f as FolderItem

f = SpecialFolder.Desktop

var tempf as FolderItem

tempf = f.child(“test”).child(“thisisafile.txt”)

//msgbox tempf.NativePath

if tempf.Exists = false then
msgbox “does not exist”
end

It now returns a NIL for tempf

Although the temp file does not exists, it is a valid folderitem. Why would this return NIL? If this is now intended, what is the need for .exists? This will break code for sure.

9

So your desktop folder doesn’t exist? Or you just didn’t test what you said wasn’t working and provided for us to test? :grin:

10

When this Folderitem tempf does not exists, it returns tempf as nil. That something changed in R2

That was not the case with Xojo 2026R1.2 and you could use .exists to see if the folderitem exists or not.

Basically this renders .exists useless. It will crash your app with a nil error. Breaking a lot of code.

Of course you can now check if tempf is nil or not. But again, what’s the point of having .exists?

11

One thing I learned many years ago is that you never assume a FolderItem is non-Nil. Always verify and/or catch potential exceptions.

4 Likes
12

@Anthony_G_Cyphers
:100:

1 Like
13

Agreed

This also provides an opportunity to either create the entire path or provide a more useful error message to the user since you should be checking every item in the path.

3 Likes
14

Well yes, that’s true. But in that case, .exists should be removed. Right?

15

No. There’s a difference between an invalid path (or an uninitialized variable which contains no value) and a non-existent file at a valid path. The parent directory doesn’t exist, so the child would be invalid, not just non-existent.

1 Like
16

While this change is good for consistency, it sucks logically. I expect it does this due to some underlying behavior on other platforms, but it still doesn’t make sense.

Call SpecialFolder.Desktop.Child("thisDoesNotExist") // Non-nil FolderItem with Exists = False
Call SpecialFolder.Desktop.Child("thisDoesNotExist").Child("thisAlsoDoesNotExist") // Nil FolderItem
Call SpecialFolder.Desktop.Child("thisDoesNotExist").Child("thisAlsoDoesNotExist").Child("surprise!") // NilObjectException
17

I don’t use Mac but this is how Xojo has operated on Windows for as long as I’ve known it so I’ve just got used to it.

If you consider that Xojo doesn’t have methods to create a full path all in one go, then it actually makes sense.

Non-existent children of folders have to return valid FolderItem objects with Exists = False, as you need the object reference to be able to call .CreateFolder to create the path step-by-step going downwards.

Going one step beyond a non-existent child creates an invalid path and returns Nil, so that you can’t pass this as an invalid target for operations like .CopyTo and .MoveTo

2 Likes
18

I do most of my work on Windows and Linux but also use macOS and I have always expected this behavior as @Lawrence_Johnson and @Anthony_G_Cyphers have described.

1 Like
19

Oh I know why it happens. It’s still allowed to be stupid.

But you can create a FolderItem from a full path with the constructor.

20

And that now throws an exception if the path is invalid, so now it’s consistent.

https://tracker.xojo.com/xojoinc/xojo/-/issues/79365