>I remember a few (?) months ago there was a protracted discussion about
>where HANDLEEVENTS commands should be put in an app.
>
>In my current project, I have a FN that scans either a folder or the folder
>and all sub folders, which can take some time considering the size of HDs
>these days.
>
>To keep other apps happy while I'm trolling a folder/HD I've put a
>HANDLEEVENTS in the main FN and it doesn't seem to have caused problems and
>it does allow other apps to get some CPU time.
>
>Was there a consensus about the pros & cons of doing this sort of thing ?
>
>--
>Pete...                     (the other one)


I say add that Handleevents where you need it and don't worry about it.

Think about it...when you have it in the main loop:


Do
HandleEvents
Until gQuit

It is getting called kazillions of times anyway.

Just thowing another one somewhere isn't going to corrupt anything ( I
don't see how it could). You are merely moving events checking along faster
if anything (imho)

All HandleEvents calls in the abstract (FB3) is FN WaitNextEvent, then
proceeds from there.

There are some runtime events that get handled if need be, but still, you
are just making a call to it earlier than otherwise.

Sometimes when I am starting up a program that does animation or something
right at the beginning, to avoid that stuttering as things crank up, I have
before my regular do/until loop:

DIM i


For i = 1 to 10
HandleEvents
Next i

FN NeedToDoSomething

Do/HandleEvents
until gQuit


And that will usually refresh/load up anything, and any animations crank
right up from the normal event loop then.

Just thow in a check to FN Tickcount, and if the time gets beyond some
value, call HandleEvents, then reset your timer.

4.21¢

rc