In Python's tkinter, a student writes `Button(root, text='Save', command=save_file())`. The file is saved once when the program starts, and clicking the button does nothing. Why?
Atkinter buttons can call a function only once
Bsave_file() runs immediately while the button is built, and its return value (None) is registered instead of the function
CThe button needs a second argument naming the event type
Dsave_file must be defined after the button is created
Writing save_file() calls the function on the spot and passes its result to command. The correct form is command=save_file, which passes the function object so tkinter can call it each time the button is clicked.
Question 2 True / False
In an event-driven program, event handlers always run in the order they are defined in the source code.
TTrue
FFalse
Answer: False
The order depends on when events happen. If a user clicks 'Stop' before 'Start', the Stop handler runs first, even if it is defined later in the file.
Question 3 Multiple Choice
A click handler in a single-threaded GUI program runs a loop that takes 10 seconds. What does the user most likely see during those 10 seconds?
AThe window keeps responding normally, because each click gets its own copy of the program
BThe window stops responding to clicks and redraws until the handler finishes
CThe program crashes immediately
DThe loop is skipped, because handlers cannot contain loops
The event loop calls one handler at a time and cannot process other events until that handler returns. Long work is usually split up, scheduled with timers, or moved to a background thread or asynchronous task.
Question 4 Short Answer
What is an event loop, and why do most event-driven programs not need to write one themselves?
Think about your answer, then reveal below.
Model answer: An event loop repeatedly waits for the next event, finds the handler registered for it, and calls that handler. GUI toolkits, browsers and game frameworks supply the loop (for example tkinter's mainloop()), so the programmer only writes and registers handlers.
This division of labor is the core of the paradigm: the framework owns the control flow, and the programmer supplies the reactions.