realbasic-nug
[Top] [All Lists]

Re: 101 error when deleting a file

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: 101 error when deleting a file
From: Charles Yeomans <charles at declareSub dot com>
Date: Mon, 28 Apr 2008 17:22:29 -0400
Authentication-results: mx.google.com; spf=pass (google.com: domain of realbasic-nug-bounces at lists dot realsoftware dot com designates 66.116.103.65 as permitted sender) smtp dot mail=realbasic-nug-bounces at lists dot realsoftware dot com
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <5EB05FDE-421A-41F0-BB4C-7431082362E5 at frontiernet dot net>
On Apr 28, 2008, at 4:34 PM, Harrie Westphal wrote:

> Is there a logical reason why REALbasic sets FolderItem.LastErrorCode
> to 101 when you delete a file? Watching the events in the debugger
> you can see that the file exists, has been read in and it shows the
> f.exists=true, f.LastErrorCode=0. Now when f.delete is executed
> f.exists goes to false, which I would expect, but f.LastErrorCode
> goes to 101, which seems odd. Yes, the file no longer exists which is
> what 101 is telling you, but it existed at the point in time when the
> f.delete was executed so why throw a 101 error at that time? I guess
> you could argue that that is verification that the file was deleted,
> but f.exists going to false would also tell you that. Just seems odd
> to me.


It is odd, and has been the source of some problems for me.  My  
solution is never to depend on FolderItem.LastErrorCode.  Instead I  
attempt to check the outcome of a FolderItem method call as best I  
can, and use LastErrorCode only for logging.

Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>