>
> > 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?
Register for sysNotifyDBCreatedEvent notification.
>
> Perhaps call DmNumDatabases on each step and verifying that the number
stays the same - but that will cause slowdowns
DmNumDatabases(() is pretty fast. (At least was in the older OS versions -
just a lookup into some memory location.)
> 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).
The worst thing that can happen is that some DB will be skipped.
> And, when scanning the card, I can't do even that. :-(
Even worse - the iteration could fail. 2 remarks:
- Changing a card file by a bkg app is probably a very seldom scenario.
- This change can happen only on predetermined places - when you call
EvtGetEvent(). What about making this call only after the directory scan is
over? (I know - large directories etc. But something like this...)
>
> 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.
That's what I call background processing.
>
> 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. :-(
The notifications mentioned above should help.
>
> > > 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.)
Implement GetNextFile() like this:
Keep the directory list along with the enumeration. At the beginning the
dirList is initialized to the root dir.
1. Pop a directory from the dirList or terminate (empty dirList).
2. Start directory enumeration.
3. If the enumeration yields a file, return it.
If a directory is obtained, add it to the dirList.
If the enumeration ends, go to step 1.
The recursion is replaced by maintaining a dynamic list of directories.
(E.g. dynamic list of strings.)
>From the outside the caller will see it non-recursively. (GetNextFile()
function)
>
> 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.
Yes, but I would consider it safe only for a fg application.
Imagine an app that performs a modal event loop as part of processing of the
dialog button press. (I.e. called from the form handler of the active
dialog.)
Assume further that the active form did not change.
In this scenario the bkg application cannot do what you suggest.
Regards,
Jan Slodicka
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
