> is there a fast way of determining how many files are present on the > card? > > No
Drat. :-( Thought so. That also means no reliable progress indicator during the traversal - because I won't know in advance who much work there is to do, so I won't know what part of it I've already done. There are heuristic algorithms to solve this problem at least approximately - but they are probably not worth the effort here. > Basically yes, but if you act as a foreground task and the DB > processing is fast, then you should consider processing of > multiple databases in one step. I thought about this but I don't think that it is needed. My current implementation works well enough. > If you write a bkg DB, then you should somehow cope with possible > DB changes while running the loop. (In fact the DB changes are > possible in the first scenario, too. Maybe reacting on respective > notifications...) Hmmm... How do I solve that? In fact, how do I even detect it? Database changes aren't exactly a problem - once I've finished with a database, it doesn't matter whether it changes; I'll process the change on the next scan. If I haven't started examining it yet it also doesn't matter - I'll process it when I see it. It's the adding or removing of whole databases that will screw the things up - but how can I detect that this has happened? Perhaps call DmNumDatabases on each step and verifying that the number stays the same - but that will cause slowdowns and is unreliable (somebody might remove a database I haven't processed yet and add a new one; that could be enough to interfere with the DmGetNextDatabaseByTypeCreator loop). And, when scanning the card, I can't do even that. :-( As for background processing - what's your definition for that? I'll invoke my application on some events (e.g., launching of an application) - but then I'll scan only one database. I'll scan multiple databases on other events - like memory card insertion or HotSync completion - but it is unlikely that a database will be added or removed while I'm doing this. The main danger, as I see it, if an alarm triggers while I'm scanning multiple databases and, as a result of the alarm, a databases is created or removed. But I don't see how I could cope with that. :-( > > Implementing a non-recursive directory tree traversal is a bitch > > - basically, I'll have to implement the recursion "manually" by > > organizing a stack and saving there the intermediate variables > > of the function that returns the next file... > > That's easy. Is it? :-) Do you have any pointers to examples how to do it? (Non-recursive directory traversal, that is.) > If the speed is a factor, then you might find that some > arrangements work better. E.g. opening the files during the > enumeration of the parent directory is much faster than > remembering the file paths and opening them after the directory > is closed. Oh, yes, certainly - I intended to do that from the beginning. There could be thousands of files on the card - I can't afford to collect them all in memory first, before starting to process them. I must process them one-by-one, as I find them on the card. > Either this You mean, the method I proposed would actually work? Is it a reliable way to give some time slice to the OS to handle its events? There was a function for that in cooperative multi-tasking systems like Windows 3.x - but not in PalmOS. > or the other way around - calling your enumerator from the main > event loop to do a few steps on each nilEvent. But that presumes that the enumerator is written in a non-recursive way, so that it can handle only one step (i.e., find the next file) every time it is invoked - and I'm a bit uncertain how exactly to do that. Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
