>Right now, I think you're OK, but I can easily imagine an implementation in
>which the sorting happened from a different task -- like the
>synchronization task. In that case, doing UI from the comparison function
>would be really bad.
>
>In general, your comparison function should be self contained and re-entrant.
>
>Again -- that isn't a requirement right now, so you'll be fine if you do
>this in existing implementations, but you might want to note it in your
>source so you can easily find/fix it later, just in case.
I liked Neil's suggestion, although it only addresses the "how to keep
the beach ball spinning" problem, not the "how to abort the process"
problem. Bob, if this routine is ever rewritten, it might actually be
nice for it to put up its OWN UI (Cancel button), allowing the user to
cancel out of a sort (which should leave the database partially sorted,
but still perfectly functional). Of course this could be one more
parameter in the call to the API, like true puts up a Cancel button and
false doesn't or something. When you sort a 10,000 record database it can
take a while (not nearly as long as installing it in the Palm to begin
with!!!), and the fact that the unit appears frozen during that time
isn't a good thing. Heck, while we're at it, maybe sort should do its own
spinning beach ball. :-)
To summarize - indications of activity and possibilities of cancellation
are HIGHLY desirable for operations that can take 30 seconds.
Steve Patt
President, Stevens Creek Software
http://www.stevenscreek.com/pilot
The home of...
PalmPrint && UnDupe && AreaCoder && Handy Randy
Athlete's Calculator && PocketTimer && SnailMailer
Athlete's Diary && On Hand && Take An Order! && many more
