Thomas Reed wrote:
>This is hardly new behavior. Once, years ago when I was still
>programming exclusively in C, I tried to create a Finder-like file
>browser interface. I ran into significant problems, however, when
>the user made certain kinds of changes via my interface, such as
>dragging a file to a new location in a Finder window. I could remove
>the file in such a case, but wouldn't know whether -- or where -- to
>add it back to the list. Re-building the list did no good, as the
>changes might not be reflected yet. The only solution I could come
>up with was rebuilding of the list every few seconds to ensure it was
>up-to-date. In long lists of files, this was a poor solution at best.
Well, I wonder if you have overlooked something.
With OS 9 and before, it all worked well, AFAIK:
When calling the low level file/directory OS functions that
gave you the count of files in a dir, this value was ALWAYS up to
date, never delayed (this I am 100% sure about since I've written
File Systems and know the File Mgr very well).
If you wanted the Finder to update its open window after you
had modified something in it, all you had to do was to update
the folder's modification time.
So does the Finder, which means that you only had to monitor
your browsed folders' mod times to know when they needed an update,
and then using PBGetCatInfo would return the current state of
all files in the dir, for sure.
Or did you do exactly this and it did not work?
Thomas
--
Thomas Tempelmann,
http://www.tempel.org/rb/
---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>
Unsubscribe:
<mailto:realbasic-betas-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-betas-digest at lists dot realsoftware dot com>
.
|