🚀 go-pugleaf

Helmut Giese wrote:

>a console mode app of mine needs to periodically perform some action
>while still being able to react to input from the user.
>I thought that the combination of getting the handle to the input
>console and then doing a WaitForSingleObject with a suitable timeout
>would accomplish what I need - but it doesn't work.

Have you tried ResetEvent( inHdl ) ?
Maybe FlushConsoleInputBuffer( inHdl ) ?

The docs for ReadConsole don't mention waiting, but the docs for
ReadConsoleInput do. You might try that function.

My own code uses polling with a Sleep( 10 ) because I also check for
UDP messages. Several copies of the program can run with no
notiiceable delays.

I also allow mouse clicks which brings in mouse movements as well
(which I ignore).
	GetNumberOfConsoleInputEvents( stdin, &written );
	if( 0 == written )
	{	++WaitCounter;
		if( WaitCounter > 100 )
		{	WaitCounter = 0;
			BackgroundProcess();
		}else{
			Sleep( 10 );
		};
	}else{
		ReadConsoleInput( stdin, &input_record, 1, &written );
		// if you want background to only fire after
		// 1 second of inactivity
		WaitCounter = 0;
	};
See Reading Input Buffer Events
http://msdn2.microsoft.com/en-us/library/ms685035.aspx

  -  -  -  -

In any case, the usual method these days is to use threads.
Main() could create a CancelEvent, then start the background thread.
When main() wants to exit, it signals CancelEvent to terminate the
background thread.
Main() could also set a global boolean whenever it processes a
keystroke.

The background thread could WaitForSingleObject on the CancelEvent,
and process during WAIT_TIMEOUT, exiting on WAIT_OBJECT_0.

while( 1 )
{	if( WAIT_OBJECT_0 == WaitForSingleObject( CancelEvent, 1000) )
		break;
	if( GlobalKeyPressed )
	{	// key was pressed while we slept
		GlobalKeyPressed = false;
	}else{
		BackgroundProcess();
	};
};

This has the advantage of being responsive even when the background
thread is busy.

Whichever thread method you use, you would also want to add
	SetConsoleCtrlHandler( &CtrlHandler, TRUE);
to catch the Big Red X and other app closers so you can signal the
thread to exit nicely.

Hi Bob,
many thanks for the info - lots of ways to chose from.
- Calling FlushConsoleInputBuffer did not change anything
- going the multi-threaded way looks a bit like too much effort for
this particular app,
- so I think I use your polling example

Oh, and thanks for the link to Input Buffer Events.
Best regards
Helmut Giese

 in addition..

    while (!dgDone)
    {
        // standard console processing
        //
        INPUT_RECORD lpPeekBuffer = { '\0' };
        DWORD dwNumEventsPeek = 0;
        ::PeekConsoleInput(inHdl,                     // handle to a console 
input buffer
                           &lpPeekBuffer,                  // pointer to the 
buffer for peek data
                           sizeof(INPUT_RECORD), // number of records to 
read
                           &dwNumEventsPeek);        // pointer to number of 
records read
        if(dwNumEventsPeek)
        {
           read the console .. it has events.
        }
      do something else
     repeat..
}

--
Michael


"Helmut Giese" <hgiese@ratiosoft.com> wrote in message 
news:7vtls2tbtoeo4qv75aqhaj8l2e8rvlfrp1@4ax.com...
> Hi Bob,
> many thanks for the info - lots of ways to chose from.
> - Calling FlushConsoleInputBuffer did not change anything
> - going the multi-threaded way looks a bit like too much effort for
> this particular app,
> - so I think I use your polling example
>
> Oh, and thanks for the link to Input Buffer Events.
> Best regards
> Helmut Giese
>