Doevents Equivalent for C++

DoEvents equivalent for C++?

DoEvents basically translates as:

void DoEvents()
{
MSG msg;
BOOL result;

while ( ::PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE ) )
{
result = ::GetMessage(&msg, NULL, 0, 0);
if (result == 0) // WM_QUIT
{
::PostQuitMessage(msg.wParam);
break;
}
else if (result == -1)
{
// Handle errors/exit application, etc.
}
else
{
::TranslateMessage(&msg);
:: DispatchMessage(&msg);
}
}
}

What is equivalent to Application.DoEvents() in WPF applications

You shouldn't be using it even in Windows Forms. Don't perform long-running tasks on the UI thread - use a background thread and use the Dispatcher to update the UI as required. Any use of Application.DoEvents is basically a code smell. I don't know whether there is an equivalent in WPF, but you should try to avoid it even if there is.

Avoid Application.DoEvents() in C#

If you are using .NET 4.5 it is really easy to do with async/await and a TaskCompletionSource and async/await.

TaskCompletionSource<string> resultTcs = new TaskCompletionSource<string>();
private async Task<string> SendCommandAsync(string command)
{
serialPort1.Write(command); // send the command

var timeout = Task.Delay(500);

//Wait for either the task to finish or the timeout to happen.
var result = await Task.WhenAny(resultTcs.Task, timeout).ConfigureAwait(false);

//Was the first task that finished the timeout task.
if (result == timeout)
{
throw new TimeoutException(); //Or whatever you want done on timeout.
}
else
{
//This await is "free" because the task is already complete.
//We could have done ((Task<string>)result).Result but I
//don't like to use .Result in async code even if I know I won't block.
return await (Task<string>)result;
}
}
private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
var response = serialPort1.ReadExisting();
tcs.SetResult(response);

//reset the task completion source for another call.
resultTcs = new TaskCompletionSource<string>();
}

What to use instead of Application.DoEvents in my game?

I'd suggest to make that event handler async and use await Task.Delay() instead of Thread.Sleep():

private async void Game_Screen_KeyDown(object sender, KeyEventArgs e)
{
for (int i = 0; i < 500; i++)
{
if (e.KeyCode == Keys.Left)
{
cannonBox.Location = new Point(cannonBox.Left - 2, cannonBox.Top); //Changes location of cannonBox to a new location to the left
await Task.Delay(10); //Delays the movement by couple milliseconds to stop instant movement
}

if (e.KeyCode == Keys.Right)
{
cannonBox.Location = new Point(cannonBox.Left + 2, cannonBox.Top); //Changes location of cannonBox to a new location to the right
await Task.Delay(10); //Delays the movement by couple milliseconds to stop instant movement
}

if (e.KeyCode == Keys.Up)
{
createLaser(); //Calls the method whenever Up arrow key is pressed
}
}
}

This way, the control flow is returned to the caller and your UI thread has time to handle the other events (so no need for Application.DoEvents()). Then after (about) the 10ms, the control is returned and execution of that handler resumed.

There may more fine-tuning be necessary, because now of course you could manage to hit more keys while the method has not finished. How to handle that depends on the surroundings. You could declare a flag that signals current execution and refuses further method entries (no thread safety needed here as it's all happening sequentially on the UI thread).

Or instead of refusing re-entrance queue the keystrokes and handle them in another event, e.g. "idle" events (like Lasse suggested in the comments).


Note that an event handlers is one of the rare occasions where using async without returning a Task is ok.

Where is the Application.DoEvents() in WPF?

The old Application.DoEvents() method has been deprecated in WPF in favor of using a Dispatcher or a Background Worker Thread to do the processing as you have described. See the links for a couple of articles on how to use both objects.

If you absolutely must use Application.DoEvents(), then you could simply import the system.windows.forms.dll into your application and call the method. However, this really isn't recommended, since you're losing all the advantages that WPF provides.

C# Equivalent of VB 6 DoEvents

Application.DoEvents() (part of WinForms)

iPhone equivalent of Application.DoEvents();

Generally speaking you want to avoid DoEvents. The iPhone equivilant in objective-c looks something like this:

[[NSRunLoop currentRunLoop] runUntilDate:[NSDate date]];

With what to replace WinForms Application.DoEvents() in a C# class library?

  1. If you really want to use it, you can always include system.windows.forms.dll to your project.

2, the only reason you call Application.DoEvent is allowing the application to handle other events when your event is processing. Hence, you want to wrap your event in a separate thread such as using a BackgroundWorker or a Thread object to emulate an async call. In WPF, there is a Dispatch you can invoke or beginInvoke to execute a method asynchronously.

Use of Application.DoEvents()

From my experience I would advise great caution with using DoEvents in .NET. I experienced some very strange results when using DoEvents in a TabControl containing DataGridViews. On the other hand, if all you're dealing with is a small form with a progress bar then it might be OK.

The bottom line is: if you are going to use DoEvents, then you need to test it thoroughly before deploying your application.



Related Topics



Leave a reply



Submit