In the last ~6 months (on Yosemite and now El Capitan) I’ve had a few dozen reports of problems opening files that are on the HD, the error message being:
error The path passed into new FolderItem was invalid
I cannot reproduce this problem. In the latest example, this is the code that I think gave the error:
f = GetOpenFolderItem("text;xml")
This works 99.9% of the time, but in some cases gives this error. I’ve suggested that the users reboot or relaunch the Finder, which seems to fix it (at least they don’t get back to me with more problems).
This code has worked without problem for as long as I can remember, but recently has resulted in this intermittent problem. Any idea of what’s going on?
It’s not my file, it’s dozens of different files from dozens of different users (it’s a commercial application, I’m getting error traces automatically sent to me). These are legitimate Mac file names AFAIK. I’ll try to have one sent to me, but since rebooting seems to take care of it I doubt I’ll see anything unusual.
It matters in that you wrote " you have a file". I don’t, my users do. With so many reports of this I very much doubt that any of these files has illegal characters. And if they did, why would rebooting make any difference – illegal is illegal?
However, I’ve written to some who have reported this to obtain the files and we’ll see. Since this isn’t ringing a bell with anyone, I’ll have to hope I can reproduce it.
Hm, I didn’t fully understand your initial reply (why mention ; ?), but perhaps you were referring to my code
f = GetOpenFolderItem(“text;xml”)
If so, those are the Xojo file types I’m screening for (and are defined as distinct file types in my project). Are you saying I’m doing that incorrectly?
BTW, I created a file with a ; in the name and Xojo handled it without a problem.
Because I have a stack trace, and I know (in one instance, at least) that the user was opening an XML file. And this is the line where that would occur.
In your example, you have a /, which is not allowed in OS X. But we’re getting far afield. The error is “The path passed into new FolderItem was invalid”. I suspect that’s not from Xojo, but would be interested to hear if I’m mistaken.
Yeah, I’m just showing that this will cause the error message you’re seeing and thought maybe you have a “new Folderitem” somewhere because I can’t get GetOpenFolderitem(garbage) to exception.
I also got the same error, one of my programs search preference information in a folder and sometimes it seems that the path does not exist, then I give restart the Mac and when he returns to work everything is ok, do not worry much even for now is sporadic as it does not interfere in the normal work, but it is very strange problem.
I have no idea how GetOpenFolderItem is actually coded, but if it first calls the file picker and then turns to GetFolderItem to create the actual object, then it would make sense. Now since the issue resolves itself with a restart, I would be tempted to suspect a random Cocoa bug.
I tried to search the Apple forums, but the haystack was uncooperative.
I have more information about this. It looks like a Xojo bug to me, but perhaps there is some internal logic to the way it is behaving that escapes me.
s = “/Users/validfolder/Documents/fileDoesNotExist”
f = new FolderItem(s, FolderItem.PathTypeNative)
returns a folderItem (f) where .exists = false. This is what I would expect.
But if I point to an invalid folder (rather than a file) like this
s = “/Users/folderDoesNotExists/Documents/fileDoesNotExist”
f = new FolderItem(s, FolderItem.PathTypeNative)
I get a UnsupportedFormatException error with the message: “The path passed into new FolderItem was invalid”
To me the path passed was entirely valid, it just didn’t point to an existing item.
And the reason I think this is a bug is that if I don’t specify FolderItem.PathTypeNative, I get no error.
s = “/Users/folderDoesNotExists/Documents/fileDoesNotExist”
f = new FolderItem(s)
I get a non-nil folderItem to a file that does not exist.
Norman, the behavior is inconsistent and strikes me as a bug…agree or not?
A FolderItem can only represent one level of non-existence, which is why you get the exception.
In the case where you don’t pass FolderItem.PathTypeNative, you’re actually getting a very different FolderItem than what you expect. It’s being interpreted as an HFS path.
The analogy I can think of is that if I specify f.child(“doesnotexist”) I get a valid folderItem that does not exist, but if I specify f.child(“doesnotexist”).child(“doesnotexist”) I get a NOE (the first child evaluates to nil, so the second yields the exception).
But in my case I would not expect a UnsupportedFormatException to be thrown (which confused the heck out of me, since I kept thinking there was something wrong with the way the file path was represented). I would have expected Xojo to take care of the problem and deal with it by providing a folder item where .exists = false. Or at least a NOE, which would seem to be closer to the mark.
Now that I understand it I can of course deal with it by wrapping these calls in try…catch blocks.
I read the section on folderitem multiple times but didn’t make note of this (in my defense, there is a lot of info there). Thank’s for pointing it out.