Re: The basics of Windows' messages
- From: adebaene@xxxxxxxxxxxxxxxx
- Date: 7 Jun 2006 00:58:21 -0700
Ney André de Mello Zunino a écrit :
<snip>
If no special measure is taken, the consequences are anything but nice.
As mentioned in your response, if an application does not process
messages timely, it will appear to be hung; in other words, it will not
be responding to the user's input, requests for repainting by the
system, etc.
The two workarounds for this situation which I know are:
1) write the lengthy processing as a separate thread; or
2) force the application to periodically deal with its message queue.
I would like to focus on item 2) for now.
William as already answered your questions about 2) in great details,
but I would like to add that most experienced developers consider 2) to
be a bad choice, and 1) to be the correct solution.
The main reason for that is that, if you follow the 2) way, you need to
add calls to ProcessMessages/DoEvents/PeekMessage loop inside your
lengthy processing code, which is an anathem from an encapsulation
point of view, and is never an ideal solution. Among other things, how
often you must run the PeekMessage loop in order to keep the UI
responsive enough for the user depends on the lengthy treatment, but
also on the speed of the target machine.
Arnaud
MVP - VC
.
- Follow-Ups:
- Re: The basics of Windows' messages
- From: Ney André de Mello Zunino
- Re: The basics of Windows' messages
- References:
- The basics of Windows' messages
- From: Ney André de Mello Zunino
- Re: The basics of Windows' messages
- From: William DePalo [MVP VC++]
- Re: The basics of Windows' messages
- From: Ney André de Mello Zunino
- The basics of Windows' messages
- Prev by Date: Re: MTA with Thread Pool API
- Next by Date: Re: C/C++ calling convention
- Previous by thread: Re: The basics of Windows' messages
- Next by thread: Re: The basics of Windows' messages
- Index(es):
Relevant Pages
|