[ATTENTION], "problem" with FolderItem.Exists

[jda]

>On Feb 21, 2005, at 9:03 AM, jda wrote:
>>
>>Kevin, do you use RB? I ask because if you do you should know that 
>>GetSaveFolderItem (see above) is a standard method for obtaining a 
>>folderItem prior to saving a file to disk:
>>
>>f = GetSaveFolderItem("", "database1")
>>
>>It puts up a standard "Save As" dialog box.
>>
>>If you click Save and the file already exists, you are asked if you 
>>want to replace it with a new file. You can cancel or proceed. If 
>>you proceed, a folderItem is created. Valentina hasn't yet entered 
>>the picture.
>
>Does the bug only occur with a folderitem created from GetSaveFolderitem?

Yes, as far as I can tell.

>  How does valentina know that?

It doesn't. It's a bug in RB, which does know it.

>  I am looking at this from an API perspective. Not from the user 
>perspective. What if the developer passed in a folderitem that 
>existed and didn't use the GetSaveFolderitem. Wouldn't the bug still 
>happen?

No.

>  Now the user has lost a file that they didn't agree to losing.

That's the programmer's fault. RB will overwrite a file if the 
folderItem points to one, for example, f.createAsTextFile

>
>Like I said, this is just my opinion, but a command called create 
>should create something, not destroy something. I personally would 
>not intentionally choose to allow a create command that I put in one 
>of my own programs to destroy something. It's unexpected and 
>counter-intuitive.
>
>That's all I'm getting at. It's a separation of powers kind of thing.

This is how the Mac works. It's up to the programmer to ensure that 
the user doesn't overwrite an existing file unintentionally. That's 
what the check in Save As is for. And that's the way it should be.

Jon