That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That's what setting the cursor to the wait cursor (the hourglass) is for.
Very commonly for apps that otherwise respond just fine, someone somewhere will provide it more data than it can process in an acceptable amount of time, and cause it to become "not responding". I have a feeling that putting up the wait cursor stops that, but I could be wrong.
It's not always easy or even practical to process user input while you're busy.
Of course we should all try hard to keep our app responsive, for our users sake.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
It doesn't have to respond to everything I want, but it should at least allow me to exit, if I've accidentally started an operation that is going to take six hours to finish. Having an app go to la-la land with the only way to kill it being the task manager is just junk coding. Forcibly killing the app could corrupt data.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}