Joseph M. Newcomer wrote:
OK, then the issue here is that you would have a timer handler something like
if(nIDEvent == IDT_MY_REQUEST)
{
if(active)
DoDatabaseQuery();
}
where you would have handlers like
LRESULT OnSetQueryActive(WPARAM wParam, LPARAM)
{
active = (BOOL)wParam;
return 0;
}
So you could PostMessage(UWM_QUERY_ACTIVE, TRUE) to enable the database queries, and use
FALSE to disable the database queries, so this would "pause" the thread. You could also
set it up so that the code was
..OnSetQueryActive(..)
{
if(active == (BOOL)wParam)
return 0; // no change
if(!active && (BOOL)wParam)
{ /* reactivate */
DoDatabaseQuery();
SetTimer(60000, IDT_MY_REQUEST, NULL);
return 0;
} /* reactivate */
else
{ /* deactivate */
KillTimer(IDT_MY_REQUEST);
return 0;
}
}
Note that activating the queries causes an immediate query with this code, and then one
query a minute thereafter. FALSE simply shuts the timer off, the thread itself is still
responsive.
Note that the secondary UI thread should not have any user-visible windows that it is
manipulating. That leads to a lot of potential problems.
joe
On Tue, 16 Oct 2007 20:21:53 +0100, Pedro Ferreira <none@none.com> wrote:
Thanks for your help.
I'm sorry for not explaining better. In "need it to be responsive", the
"it" was referring to the secondary UI thread :)
I needed to be able to pause or query the secondary thread even when it
was "waiting" 1 min between cycles. This would exclude any Sleep() call.
Pedro Ferreira
Joseph M. Newcomer wrote:
I presumed that by "keep the UI responsive" the OP meant that there should be no blocking
calls in the main UI thread itself; that the secondary UI thread would be doing background
work. So the main GUI thread would not be blocked, but the UI thread provides a nice
queueing mechanism, and doesn't require any PeekMessage hacks.
For example, see my serial port example on my MVP Tips site, which uses a worker thread to
handle input but a UI thread to handle output.
joe
On Tue, 16 Oct 2007 07:31:31 GMT, jetan@online.microsoft.com ("Jeffrey Tan[MSFT]") wrote:
Hi Joseph,
Yes, I agree that using the build-in message queue of the GUI thread will
make us a bit easy for coding. But, as the OP stated, he wanted to keep the
UI responsive, so I assume that he will show visible windows. Then, this
depends on whether his background work is length or not. If the background
work will cost a lot of time, it definite will block the GUI message
dispatching which causes non-responsible for this UI thread. Sure, we may
use PeekMessage to lighten this problem.
Anyway, this depends on the OP's specific scenario. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm