I am doing some error checking on a file open dialog and looking at the available properties and error codes, to try and make my dialog as bullet proof as possible.
FolderItem.LastErrorCode can be one of :
0 - OK
101 - File not found
102 - Access denied
103 - Not enough memory
104 - File in use
105 - Inavlid name
(Ignoring 100 since I’m not copying or moving anything, only opening an existing file)
I am then looking at several properties which can indicate a possible issue, like so :
It appears there could be some correlation between some of these :
‘101 File not found = (Not FolderItem.Exists)’
‘104 File in use = (Not FolderItem.IsWriteable)’
‘105 Invalid name = (FolderItem = Nil)’
Can anyone confirm if any of the LastErrorCode(s) are the equaivalent of checking the FolderItem properties above, or do I need to account for both sets of eventualities ?
I’ve just learned that we may need to do both. I’m checking for f.exists before calling f.delete, but I’m getting a LastErrorCode pof 101 (which I don’t understand how this could occur).
Whether applying one or both sets of checks, there has to be a logical sequence to it. I suspect something along these lines in the case of FolderItem checks :
If FolderItem <> Nil Then ' We have something in there.
If FolderItem.Exists Then ' The file still exists
If FolderItem.IsReadable Then ' We can at least read it
If FolderItem.IsWriteable Then ' See if we can write
If Not FolderItem.Locked Then ' Not locked
// Do something here because everything appears to check out ok
Else
// Deal with 'locked'
End If
Else
// Deal with not writeable
End If
Else
// Deal with not readable
End If
Else
// Deal with not exists
End If
Else
// Deal with Nil value
End If
LastErrorCode could be used with a ‘Select Case’, possibly by nesting in one level deeper under FolderItem.Locked.
A simple collection of ‘If… Then… End If’ would likely also do the job.
Not sure about the context FolderItem.Locked though. If it means we cant read or write then it would go before FolderItem.IsReadable. If it means we can read but not write, it would go after FolderItem.IsReadable and before FolderItem.IsWriteable.
Or possibly something of this order, where ‘SelectedFile’ is the FolderItem, and is placed inside a method which returns 0 if successful, or 1 otherwise :
If SelectedFile <> Nil Then
If SelectedFile.Exists Then
If SelectedFile.IsReadable Then
If Not SelectedFile.Locked Then
If SelectedFile.IsWriteable Then
Select Case SelectedFile.LastErrorCode
Case 0
// Do the good stuff here because everything should check out at this point
Return 0
Case 101
Msgbox("Error : File not found")
Return 1
Case 102
Msgbox("Error : Access denied")
Return 1
Case 103
Msgbox("Error : Not enough memory")
Return 1
Case 104
Msgbox("Error : File in use")
Return 1
Case 105
Msgbox("Error : Invalid name")
Return 1
End Select
Else
Msgbox("Error : File is not writeable")
Return 1
End If
Else
Msgbox("Error : File is locked")
Return 1
End If
Else
Msgbox("Error : File is not readable")
Return 1
End If
Else
Msgbox("Error : File does not exist")
Return 1
End If
Else
Msgbox("Error : Nil value")
Return 1
End If
You are correct, but the simple assumption that if f.Exists is true, implies that a 101 should not even be possible. The code values of 102, 103, and 104 I understand, but those are very different in this case.
Yep, hence my first post regarding possible links between LastErrorCode and certain FolderItem properties. I can see similarities but not enough to make them directly equivalent. The 10x codes look to me like they could be lower level OS related codes. LastErrorCode looks like something that is built into Xojo itself. Maybe Norman could shed some light as to whether any of these are functionally equivalent or not…