Why does graphical user interface programming often use event driven programming paradigm?

Answer 1

It's not a case of often, but always. Whenever your application is idle the application's idle loop is executed. By default, the idle loop simply processes system messages which may result in your application becoming active. For instance, as you pass the mouse over your application window, the operating system generates and posts hundreds of mouse movement messages which are passed to the message queue. The application's idle loop will process these messages and call the appropriate event handlers. Mouse movements may not be relevant to your application but they must be processed nonetheless. When the message queue is empty, the idle loop begins background processing. By default this does nothing except peak at the message queue looking for new messages for your application, but it can be overridden to perform any tasks that take your fancy (such as housekeeping tasks).

However, when the user clicks an object in your window (such as a command button), you would rightly expect your application to respond to that particular event. Thus the appropriate event handler is executed and control eventually returns to the idle loop again.

Problems occur when the event handler executes a highly-intensive task and therefore cannot yield control to the idle loop. This isn't a major problem if the task would only take a few seconds at most to complete, but if it takes any appreciable time this presents a serious problem. If your application does not process messages that are intended for it, then those messages will prevent other programs from gaining access to their messages. And as the message queue fills up, the system, grinds to a halt. Higher priority messages will still get through but the system will quickly become unresponsive.

To address this problem, your application must provide a user-defined message handler that can be periodically called by your intensive tasks, preferably two or more times every second to keep the system as responsive as possible. This message handler needn't be complex, but it must return a value to the caller to signal if the caller should abort or continue processing. For instance, if the user chooses to shut down the system mid-process, your intensive task must be able abort gracefully before the application itself can exit gracefully. This means your message handler must save and remove the message from the queue and signal the process to abort. The message handler may be called several times before the process finally aborts, but when it does control can pass to the idle loop which will finally deal with the message that caused the abort, thus permitting a graceful exit.