-
Application::DoEvents()
I have a piece of code that have Application:: DoEvents() and I have read on MSDN, but there's something that I still don't understand.
for example, here is my pseudocode:
Code:
void functionA()
{
while(true)
{
//command A;
//command B;
Application::DoEvents();
}
}
void Button_Click( System::Object^ sender, System::EventArgs^ e )
{
//do something
}
So, when program run to command A or command B, if I click -->nothing.
when run to Application::DoEvents(): if I click. Program will excute event Button Click. If I don't, program will loop again.
Does my explanation about Application:: DoEvents() true.
Please explain for me,please.
thanks :)
-
DoEvents is evil, it creates all sorts of re-entrancy issues. You might think you're improving things by making your app more responsive, but unless you precisely know very well the effects of calling it, then you will usually end up with some very bizarre and unexpected things happening.
-
This is a question about C++/CLI, which has only a distant relationship with C++. It would be better if this were moved to Windows subforum.
My guess is that, yes, if `Button_Click()` is registered as an event handler for a certain button click event and `Application::DoEvents()` is a dispatcher/message pump that forwards events/messages to their handlers then yes, it could work approximately as you described it.
-
Your app is an 'event driven' application, not a 'structured' application.
Structured is like a piece of string, the code starts at main and runs one line after the other, moving into functions and back to the calling function through the same line. i
t runs until it reaches the end of the main function and then exits.
It rarely stops or pauses.
If you want user input your app waits, not running code, until the user enters the input.
Event driven has a 'message pump'.
The message pump looks for events or messages from the OS (ie user clicks a button generates a click event).
Your app is idle when there are no events to process.
When an event is found the mesage pump sends it to an event 'handler' which is a special function that processes the event.
In your example the 'DoEvents()' means 'run the message pump and clear all the events that have built up while we were doing Command A and Command B.
So if you click the button while your app is running the Command A or B code nothing happens, the click message is sitting in the OS message queue.
When you call 'DoEvents' the message is found in the OS queue and sent to its handler (Button_Click)
-
Oh, thanks you. First time, I decide to use Timer. For each interval time, my program will check what happened from user. But, I think that is uneffective and I google, some post says about doEvents().
According to novacain post, I has one other question: when command A and command B are running, if I click button TWICE or I click button AND press a key ( suppose that my program has key_Press Event). So, when DoEvents() happen. My program will run
i) button_Click Event twice or Click_Event and Keyboard_Event
ii)just one Event.
Answer for me,please.
thanks :)
-
If you are using DoEvents to achieve something, it's a very sure sign that you should be using threads instead. Ask yourself why you are using it and what you are trying to do.
-
I have search that they say we should use DoEvents() for Simple task and Thread for Complex task.
But up to now, I still don't know all about DoEvents(). So, I don't know why people say this task is dangerous.
-
If the user clicks multiple controls while the app is running Command A and Command B they will build up in the message queue.
When you call DoEvents() these messages are removed one by one, sent to the handler and processed.
the issue the other posters are talkng about is;
Lets say the user has to click the START button to call the code to do Command A and Command B (which take some time to complete).
The user has no way of knowing that these tasks are still running becuase the UI stops responding.
So while Command A and B are running the user clicks the START button again.
The code finishes processing Command A and B and calls DoEvents()
Which finds the START button click event and calls the function to process Command A and B again. IEven if this does not cause errors in A and B processing, it takes time.
It is often better to create a worker thread to do Command A and B. The worker thread then calls PostMessage() [or similar] to inform the user of the progress.
-
Ah, now I understand why people say DoEvents() use for simple task. Because in this case (for example command A and command B) will nearly cost no time. So, our program won't have bottleneck affect.
But after your explanation, I see that this task too evil. (although for simple task, because still has many exceptions)
-