locked
Thread.Sleep() & Application.DoEvents() RRS feed

  • Question

  • Can anyone explain to me the difference between the following:

    Thread.Sleep(100);
    Application.DoEvents();

    and

    Application.DoEvents();
    Thread.Sleep(100);

    I have seen applications with the first method and some with the second
    method. Heck, I wrote some applications that I got the desired results using the first method, and some to the second. 

    Any kind of explanation will be grealty appretiated. 


    The reason I am asking because I am writing an application (UI) where I need to wait a certain amount of time before the result is acheived.  However, I have UI buttons that a user can click - and currently, when they click, the action doesn't take place until the GUI thread is done "sleeping".  I tried:

    for (..) // loop 8 times
    {
    Thread.Sleep(50);
    Application.DoEvents();
    }

    But I didn't see that much improvement. 

    Can anyone suggest something to do in order to keep my application running smoothly and at the same time, allow it to wait for a certain number of msec???
    Tuesday, August 7, 2007 5:57 PM

Answers

  • Neither one is any good.  Use a timer.

     

    Tuesday, August 7, 2007 9:24 PM

All replies

  • Practically, I can't think of any reason to prefer one over the other.  I would choose neither.  It is generally better practice to use a separate thread (say using a BackgroundWorker) for long-running background tasks instead of calling Application.DoEvents.

     

    As for your actual question, there is a difference if the thread that it's running on is the message loop thread.  If Sleep is called first, then there will be a 100 millisecond (0.1 second) delay in processing messages (fairly short, but noticeable if you are dragging the form at the time).  If Sleep is called after, there will still be a delay, but if there was a long running process already before -- long enough to build up messages -- it will wait an additional 100ms before processing.  Try changing the 100 to a 5000 and see if you can tell any difference.

     

    But if the thread where this code runs is not the message loop thread, then the message loop thread will still process any messages while this thread sleeps, so Application.DoEvents is unnecessary, and they will act equivalent.

     

     

    Edit:  Hmm, did you edit your question?  Or did I just not see your question for the right way to do this?  I would do this by launching another thread in a BackgroundWorker and do the waiting in that thread.  Try searching for BackgroundWorker for numerous examples.

    Tuesday, August 7, 2007 6:06 PM
  • Thanks! I actually was playing with the application, and I did the following:

    for (..) // loop 40 times
    {
    Thread.Sleep(10);
    Application.DoEvents();
    }



    which gave me a much better response... HOWEVER - every once in a while, the application gets stuck - when I pause the application, it is in this loop.  I think when Application.DoEvents() executes, sometimes it seems to take all the time it needs.  Does this make sense?

    One more thing - the reason that I am still heading forward with what I am asking about, and not trying to use a backGroundWorker or a different thread is this application is huge, and this was a bug reported regarding the unsmooth response to clicking when it is in a certain mode.  Hence, changing the whole structure at this point might not be the best idea, as well as all the risk involved in conducting such changes and extra time it requires!


    Thanks though for your answer... at least I know that either way is OK.


    v3ks


    Tuesday, August 7, 2007 6:41 PM
  • Neither one is any good.  Use a timer.

     

    Tuesday, August 7, 2007 9:24 PM
  • "Neither one is any good.  Use a timer"

    What and ignore the difference between synchronous and aynchronous programming? C programmers should know the difference.

    Renee
    Wednesday, January 20, 2010 11:20 PM
  • Can anyone explain to me the difference between the following:

    Thread.Sleep(100);
    Application.DoEvents();

    and

    Application.DoEvents();
    Thread.Sleep(100);

    I have seen applications with the first method and some with the second
    method. Heck, I wrote some applications that I got the desired results using the first method, and some to the second. 

    Any kind of explanation will be grealty appretiated. 


    The reason I am asking because I am writing an application (UI) where I need to wait a certain amount of time before the result is acheived.  However, I have UI buttons that a user can click - and currently, when they click, the action doesn't take place until the GUI thread is done "sleeping".  I tried:

    for (..) // loop 8 times
    {
    Thread.Sleep(50);
    Application.DoEvents();
    }

    But I didn't see that much improvement. 

    Can anyone suggest something to do in order to keep my application running smoothly and at the same time, allow it to wait for a certain number of msec???
    Hi,

    You should consider creating a new thread instead, and delegate technique.

    Thread t = new Tread....

    See the manual for details...

    As a delegate try to consider Func<T> and Lambda expression..

    cheers.
    Wednesday, January 20, 2010 11:34 PM
  • [A really late answer, but I stumbled on this thread while maintaining a legacy app, so ...]

    Re "when I pause the application, it is in this loop" - Sounds like that code is running ON the UI thread. In that case, Sleeping is counterproductive - it means you are tying up your one and only UI thread doing absolutely nothing. Now, this is a gross hack that used to be a way to allow some lower priority (background) task to get some time. Or, as you say, to "wait a certain amount of time" before continuing. But you absolutely positively cannot eliminate that delay until you get that code off your UI thread (if it is on it).

    Having said that, if the user is noticing the delay, then I doubt it is that sleep. 1/10 of a second isn't very long. The real problem is that you have code elsewhere, either on the UI thread or at an equal or higher priority, that is "hogging" the cpu. Profile your code, and find out where the real culprit is.

    Saturday, March 3, 2018 9:52 PM