pause the execution of code in one routine while letting the app respond to keyboard

  • Thread starter Thread starter Frank
  • Start date Start date
F

Frank

I'm using Sleep(100) and that works OK.

However, it would be better if my app continued to receive and process
keyboard messages.

How can I pause the execution of code in one routine while letting the app
respond to keyboard input?


Thanks
 
Frank said:
I'm using Sleep(100) and that works OK.

However, it would be better if my app continued to receive and process
keyboard messages.

How can I pause the execution of code in one routine while letting the app
respond to keyboard input?

Is it in a managed or native application that you need to do that?

Regards,
Will
 
This is native code.
I'm looping and within the loop this would work
Or receive the messages while sleeping - either way would be OK
..
..
..
sleep(100)
allow key board messages
..
..
..
 
Frank said:

Then you can try something along these lines:

MSG msg;

SetTimer(...); // Set a timer to wake you up

while ( GetMessage(&msg, 0, 0, 0) )
{
// If you have multiple timers make sure it
// is the one that wakes you up

if ( msg.message == WM_TIMER )
{
KillTimer(...);
break;
}

TranslateMessage(...);
DispatchMessage(...);
}

Regards,
Will
 
I have a loop like this in WinMain (without the timer).
Are you saying to modify that?

Or are you saying I can create a routine using your code that I can call,
instead of calling sleep, from some place in my program other than WinMain?


What I need is essentially the VB Application.DoEvents capability


Thanks for your patience
 
Frank said:
I have a loop like this in WinMain (without the timer).
Right.

Are you saying to modify that?
No.

Or are you saying I can create a routine using your code that I can call,
instead of calling sleep, from some place in my program other than
WinMain?
Yes.

What I need is essentially the VB Application.DoEvents capability

Yes. If you need to do some stuff A, stall and then do some stuff B you put
a message loop between the A and B. This can get confusing so often, but not
always, UI elements that you don't want the user to click on are disabled
before the loop and reenabled afterwards. This is what the dialog manager in
Windows does when it displays a _modal_ dialog box.

In the loop I sketched, I set a timer to ensure that the loop would see a
WM_TIMER message which you could take as a queue to end the loop.
Thanks for your patience

You are welcome.

Regards,
Will
 
Took 10 minutes, I had to look up some things but basically dropped your
code in and it worked great.

Thanks
 
| | > Native
|
| Then you can try something along these lines:
|
| MSG msg;
|
| SetTimer(...); // Set a timer to wake you up
|
| while ( GetMessage(&msg, 0, 0, 0) )
| {
| // If you have multiple timers make sure it
| // is the one that wakes you up
|
| if ( msg.message == WM_TIMER )
| {
| KillTimer(...);
| break;
| }
|
| TranslateMessage(...);
| DispatchMessage(...);
| }
|
| Regards,
| Will
|
|

This seems like a dangerous way to do things. Your program becomes
reentrant at this point, so depending on what else is happening all sorts of
things can go wrong.

If you want to pause execution, why don't you break your routine into two
pieces, and set a timer for the amount of time you want to pause.
Then in your timer handler, post a message back to your window to schedule
the second half of the task.

Anthony Wieser
Wieser Software Ltd
 
A Wieser said:
This seems like a dangerous way to do things.

It's not dangerous per se.
Your program becomes reentrant at this point, so
depending on what else is happening all sorts of
things can go wrong.

That's true but it is nothing new. Window procedures are often reentered.
It's why, by the way, that I suggested that the OP might want to disable
some UI elements before spinning the loop. Further, the OP was looking for
the equivalent of VB's DoEvents(). That's what I sketched.
If you want to pause execution, why don't you break your routine into two
pieces, and set a timer for the amount of time you want to pause.
Then in your timer handler, post a message back to your window to schedule
the second half of the task.

The OP had the pause by Sleep()-ing. The reason he posted the question was
that he needed to process messages while waiting.

Regards,
Will
 
It's not dangerous per se.

I know I can't expect people to spend much time giving tutorials in a NG but
I wonder if you can just give a brief explanation of what the above means.

What should I be looking for in my program that might make this approach
dangerous?



Thanks
 
Frank said:
I know I can't expect people to spend much time giving tutorials in a NG
but I wonder if you can just give a brief explanation of what the above
means.

What should I be looking for in my program that might make this approach
dangerous?

Reentrant:

void A() {
....
DoEvents(); // -> this might call A()
....
}

Trouble:

int i;
void B(array<T> j) {
for( i = 0; i < j.Length; i++ ) {
DoEvents(); // this might change i
j.ToString(); // which could cause an array index bounds
exception here
}
}
 
Thanks for the insight


Ben Voigt said:
Frank said:
I know I can't expect people to spend much time giving tutorials in a NG
but I wonder if you can just give a brief explanation of what the above
means.

What should I be looking for in my program that might make this approach
dangerous?

Reentrant:

void A() {
...
DoEvents(); // -> this might call A()
...
}

Trouble:

int i;
void B(array<T> j) {
for( i = 0; i < j.Length; i++ ) {
DoEvents(); // this might change i
j.ToString(); // which could cause an array index bounds
exception here
}
}
 
Frank said:
I know I can't expect people to spend much time giving tutorials in a NG
but I wonder if you can just give a brief explanation of what the above
means.

What should I be looking for in my program that might make this approach
dangerous?

You have to understand what your application is doing. :-)

Seriously, say for example, that you have an application with a menu which
has an item that causes a function to run. Say that it is in that function
where you intend to put the little "wait" snippet that I sketched. If you
did nothing else but insert that snippet, it would be possible for the user
to pull down the menu and click the menu item which would cause the function
to be called a second time before the first call returns.

That would be bad but it is not the end of the world. The simple fix in a
case like that would be to disable the menu item, run the function and then
reenable it.

It's not at all unusual in places where you find such secondary message
loops to find some disabling of UI widgets before the loop runs followed by
reenabling afterwards. Exactly what kind of fiddling you need to do depends
on exactly what your application does.

Regards,
Will
 
|I my situation the user could not cause reentrant.
| Thanks for the explanation
|


Are you sure? Press ALT+F4 while in your delayed portion.

Anthony Wieser
Wieser Software Ltd
 
What is Alt+F4. Is this it?
ALT+F4 (Close the active item, or quit the active program)

Sure didn't close my program.


I tried it but I have to press the spacebar and then Alt+F4 within one tenth
of a second.

Once I did see something on the screen but am not sure what caused it.


Thanks
 
| > Are you sure? Press ALT+F4 while in your delayed portion.
| >
| > Anthony Wieser
| > Wieser Software Ltd
| >
|


| What is Alt+F4. Is this it?
| ALT+F4 (Close the active item, or quit the active program)
|
| Sure didn't close my program.
|
|
| I tried it but I have to press the spacebar and then Alt+F4 within one
tenth
| of a second.
|
| Once I did see something on the screen but am not sure what caused it.
|
|

My prediction was that your program would process the shutdown message
WM_CLOSE, and tidy up, then destroy the window
But unfortunately, when your routine finished waiting, it would find that
all of its objects had been destroyed by the shutdown.

I can't predict what circumstance prevented that, though.

Anthony Wieser
Wieser Software Ltd
 
Back
Top