At 8:45 AM -0800 3/10/99, Scott Johnson wrote:
>But the deletion has pulled the rug out from
>under the iteration, so it crashes shortly after.
Yep, that makes perfect sense. I should have seen it.
>Final clue: this crash happens on 3.0. It runs correctly on 3.1.
Well, it probably doesn't actually run correctly, it most likely simply
doesn't crash. Probably it's now skipping some other database (because
you've changed the database directory) that might have needed the launch
code. Probably if your app is the very last one in the DB directory, then
it will still crash. (But that's very unlikely, since the DB directory is
sorted by type and creator, and 'appl' comes early in the sort list.)
I can't think of a way to induce the launch code broadcaster to re-start
the search. And in any case, doing so naively would re-send the reset code
to apps that already have it.
Probably it would be easier to make DmGetNextDatabaseByTypeCreator be more
robust when the database list changes between calls. It should be possible
for it to reset itself... I think there's enough state stored in the
searchState record to do that.
But that will only make an already complicated routine even more complex.
Perhaps the whole DmGetNextDatabaseByTypeCreator iterative model needs to
be rethought.
--Bob
