| pblais@odstrategies.org 2006-07-27, 7:55 am |
| I take a different approach. I trap the top of the EVENT loop. While
performing some critical task I disable the processing of non desired
events. You just return a Level:Notify in Thiswindow.TakeEvent in case
some other class has called you. It is a good idea to always trap a
cancel button as the user just has had enough and you should do your
best to honor a cancel request. If you always trap cancel then you can
pop up a message saying "Please wait while I do this other thing." and
return a level notify. Of course the other thing you need to look for
is the completion of what ever it is you are waiting for. A time out
feature is also kind to the user so you can ask them if they want to
still wait.
I think the idea of not knowing if some critical event is processing
is the problem. Just don't take that approach and you may find it
easier. Trap when you know a process has to block. You can't always
let the user do everything, Turn things off when they can't be on and
be sure to turn them on when they can. Always trap a cancel and either
terminate or respond. It's up to you to manage what is enabled rather
than cleaning up the mess after they attempt it.
Why have a button you can click and then pop up a message saying "no
I'm not allowing that now"? Just disable the button so they can't post
the event.
ThisWindow.Reset is a good place to enable / disable.
ThisWindow.TakeEvent is a good place to trap other events when
required. You see a critical event coming at the top of the loop and
then shut the door and look for the completed flag you need to set or
the cannel event from the user.
On 26 Jul 2006 19:16:07 -0400, "Arthur Stanford"
<eugenes@interface-solution.com> wrote:
>Before closing down a thread i need to make sure any outstanding events that
>have been posted to the thread have completed. Is there a way to .....
---------------------------------------
Paul Blais - Hayes, Virginia
|