UI freeze

[kobi]

Hello ,
Im trying to show an animated gif on a form while i read a file, but the animation freezes until all the file operation is finished

Any idea?
PS im using visual studio 2003

[Diamonddrake]

if your file is large, you might think about threading it.
or, if you load the file in a loop, then just add Application.DoEvents(); in the loop.

[kobi]

Thanks but how do i thread it , please take in mind that im redaing the file and writing the result on other file

[Diamonddrake]

post your code, I will help you.

[sknake]

Application.DoEvents(); is a very bad idea! :(

That allows windows to pump messages in the middle of your code which leads to unexpected behavior. Invoke the messages from another thread over to your UI and let it handle the repainting.

[Diamonddrake]

kinda lost me there sknake. I don't see the harm in processing windows messages during a simple read file loop. But regardless. loading the file in a separate thread would probably be the best solution.

[sknake]

It adds a lot of complexity to possible code paths:

You should not use Application.DoEvents() in order to keep your application responsive.

Calling this method will allow any waiting windows messages to be dispatched. This means if a user clicks on a button (or performs any other user interaction) that action will be processed. This can therefore cause reentrancy. If they press the same button as the one that caused the loop you are processing you will end up having the routine called again before you have finished!

Instead you should use a BackgroundWorker thread to perform the long process and then once the action is completed perform whatever additional actions are required. For example, once a button is pressed you would start the worker thread and then disable you button so it cannot be pressed again. Once the worker thread completes you would enable the button again.

http://stackoverflow.com/questions/574110/c-application-doevnets

[ddanbe]

Way back in the century that lies beyond us, I programmed a Macintosh.
Every program on it consisted of an endless loop routine which was strangely enough often called DoEvents! Inside you had to grab the next event in the queue and then via a case statement you would detect things like: was it a MouseDown and then decide if it was a Doubleclick, if the mousedown was in a menu etc. and act appropriately by calling the necessary handler routine depending on the application at hand.
I guess the DoEvents method in the Application class of C# is somewhat the same. So I think by calling DoEvents yourself, you are disturbing the Application class in some way(starting an extra endless loop)
On the other hand, it is allowed to do so! If it was not allowed DoEvents would be a private method of the Application class, or am I wrong?

[sknake]

Great explanation, that is my understanding of how it works. Regarding making it private/public -- You can do a lot of things with the .NET API that are bad ideas ;)

Basically the "main UI" thread pumps messages when the thread is idle. Provided you always perform processor intensive operations on another thread outside of the UI it will never freeze.

I don't know the reason for inclusion/exclusion of methods in the framework but as far as I know you can call .DoEvents() from the win32 API, so really any language. A lot of the .NET framework is wrapped calls to the win32 API to simplify development and this is probably another one.

Here is a blog entry regarding message pumping:
http://blogs.msdn.com/jfoscoding/archive/2005/08/06/448560.aspx

[ddanbe]

Ooops... just invented new English:twisted:
The century that lies beyond? !beyond = behind off course:icon_biggrin:

[Diamonddrake]

Interesting facts, If you have ever programed a console game, the entire idea is to create a game loop, that repeats until the game win conditions are met.

but i would say if you disable the buttons that affect your loop, doEvents shouldn't cause a problem. Microsofts documentations actually show how to use this method by using it in a load file loop. http://msdn.microsoft.com/en-us/library/system.windows.forms.application.doevents.aspx

Some Q and A from Microsoft:

Q: Why is DoEvents in the BCL namespace?

A: Glenn (Microsoft) Threading is difficult, and should be avoided if there's an easier way. If all you need to do is yield on your UI thread, DoEvents is perfect.

Q: DoEvents is evil?

A: Glenn (Microsoft) Yielding on the UI thread is a legitimate Windows programming practice. It always has been. DoEvents makes it easy, because the situations in which you need to use it are simple.

The biggest problem with doevents is it leaves the possibility to re-enable your current loop via the interface, but you can simply disable the button while the loop is in place.

Threading is hard, using a background worker can be simple. But its wrapping something so much more complicated and dangerous to you application.

Quote from codinghorror.com:

"You've never truly debugged an app until you've struggled with an obscure threading issue. Threading is a manly approach for tough guys, and it will put hair on your chest-- but you may not have any left on your head when you're done.

I agree that DoEvents is not exactly great programming practice, but even Microsoft recommends using it in lieu of hard-core threading for simple problems."

this is a simple problem, do you think the OP should tackle multi-threading? when even Microsoft says this is a prime example to use DoEvents? Don't get me wrong, the backgroundworker is a great control, you can pass it an object that can be any amount of information, have it periodically report back progress along with an object that can also be any kind of information, gets you around most of that invoke and delegate headache, and might be a good solution here. But I don't agree that a well implemented DoEvents call here would be a problem.

Either would be a viable solution that could easily come with its own bugs and issues if done incorrectly.

[ddanbe]

Although my English has sometimes some flaws in it, I like nice conversations...