A designer described the following interface
for a save operation.
Two programmers independently coded the interface using two different window managers. Programmer A used an event-loop style of program whereas programmer B used a notifier (callback) style.
(a) Sketch out the general structure
of each program.
answer available for tutors only
(a) code for Programmer A
MainLoop: repeat forever read an event if it is a keypress insert it in the filename if it is a mouse click on the 'list' button show the current directory contents if it is a mouse click on the 'save' button display the dialog box repeat forever get the contents of the filename field and put it into a variable X read an event if it is a mouse press over the 'OK' button save the file as X goto MainLoop if it is a mouse press over the 'Cancel' button goto MainLoop end repeat end repeat
code for Programmer B
Initialise: create main screen create hidden windows for directory contents and dialog box setup onKeypress callback setup onListClick callback setup onSaveClick callback setup onOKClick callback setup onCancelClick callback give control to window manager onKeypress(key): insert key in the filename field on the main screen onListClick: show the directory contents onSaveClick : display the dialog box onOKClick : get the contents of the filename field and put it into a variable save the file as X hide the dialog box onCancelClick : hide the dialog box
The natural thing is to end up with a modal dialogue box. This is certainly the case in the sample solution where the inner loop inside the 'save' button case means that any attempted interaction with the file naming box is ignored.
Suppose that Alison has typed a name and hit "Save" - she then thinks "help, is this the same name as an existing file?". Pressing the list button, even though it is visible, will have no effect as this is only considered in the outer loop. One way to fix this would be for programmer A to think "what actions do I want to work when the confirmation box is visible" and then explicitly code these.
Here the natural thing is to end up with a non-modal dialogue box. In the sample solution this is the case. Even after the confirmation box is active a press on the "list" button or typing to edit in the file name field would still work.
Suppose Brian has just entered the file name "fred" and pressed the 'save' button. He sees the confirmation dialogue box, but, at this point, he wonders whether he might be overwriting an existing file so presses the 'list' button. He sees an existing file called "fred" and so changes the filename to "freda", but realises that the confirmation box is still there and wonders whether to press "OK" - will it be saved as "fred" or "freda"?
If the toolkit explicitly manages modal dialogue boxes, programmer B may simply be able to set some sort of parameter when the dialogue box is created. Note that, like programmer A's initial solution, this would forbid clicking the list box. A trade-off: clear dialogue or maximise the user's freedom to act?
Alternatively an explicit state variable could be added to record that the dialogue box is invisible. The event handlers for the main dialogue box would then test this and not allow certain actions: