exercises

8. implementation support

EXERCISE 8.7 [extra - not in book]

(continues the scenario from question 8.5)

The designer in question 8.5 is testing one of the programs. She types in the file name "fred", presses the 'save' button and gets the confirmation dialog box. At this point she wonders whether she might be overwriting an existing file so she presses the 'list' button. She sees an existing file called "fred" and so changes the filename to "freda", but then realises that the confirmation box is still there.

Based on this information alone:

(a) do you think the program is likely to be that of programmer A (event-loop style) or programmer B (notifier)?

(b) justify your reasoning

(c) suggest a way to correct the fault

answer available for tutors only

(a) Programmer B (notifier)

(b) Because the callbacks for the main screen are still active when the dialog box is showing.

(c) Various answers possible, especially as students may have used systems of different kinds. Alternatives:

  • add a flag variable to the program that is set when in the dialog box. If the user trys to interact with the main screen the callbacks check the flag and refuse to process the event (perhaps beep)
  • as above, but when the user interacts with the main screen the dialog box is automatically hidden. But beware - potential usability problem - does this mean cancel or confirm? Given it is often hard to immediately see the effects of file-system operations this is especially dangerous.
  • the program temporarily cancels the main window callbacks while the dialog box is showing
  • the program asks the notifier to filter out and ignore events regarding the main window.
  • (cop out) some window managers offer a modal dialog box as a primitive!

Other exercises in this chapter

ex.8.1 (ans), ex.8.2 (ans), ex.8.3 (tut), ex.8.4 (tut), ex.8.5 (tut), ex.8.6 (tut), ex.8.7 (tut), ex.8.8 (tut), ex.8.9 (tut)

all exercises for this chapter