2.10.1 File Commands
The scenarios in this section cover full details of file-related commands, some of which have been introduced in preceding sections. There are two different file command menus, one in the Administrative User Interface and the Instructor Interface, and the other in the Student Interface. Since they both have the exact same commands except for the Student Interface which has commands from other menus already described in the User Interface Overview, all of the commands are covered in the following sections.
There is only one type of file which the Scheduler deals with besides the Database files which were covered in Database Management. The contents of a schedule file are as follows
All of this information is stored in a single schedule file for each schedule created by the user. In this way, a single file encapsulates scheduled classes and all other schedule-specific information that the user has defined for that schedule like the current databases. "For that schedule " means that each schedule has its own database and comment information. Each schedule contains references to the specific database that said schedule uses so there should never be any conflicts with other schedules.
Schedule files may be stored in any file directory accessible to the user. There are no naming requirements for schedule files, other than the common requirements of whichever Operating System the program is running on. In particular, there are no requirements for filename extensions. If the user chooses to give schedule files an extension, or if a particular operating environment recommends or requires that application files have known extensions, then the recommended extension for schedule files is ".sch". If this extension conflicts with that used by some other application, then the installation process can assign a particular extension to be used in a particular operating environment.
The internal data format of schedule files is not specified in these requirements, and therefore left to the implementors. In particular, there are no requirements that these files be editable as plain text or other external data format understandable to application programs other than the scheduler. It is required that the scheduler be able to identify scheduler file as such, so they can be distinguished from other types of files. The specific means to accomplish this identification is left to the implementors.
2.10.1.2 New and Open Commands
When the user executes the `New' command in the `File' menu, the system responds by creating a new schedule and displaying its initial view.
The name of a new schedule is "unnamed", until the user saves it with a different name. Each successive application of New, with no intervening save, creates a schedule named "unnamed[N]", for N = 2 to the number of unnamed schedules.
A new schedule has no scheduled classes, no comments or feedback and no current references to databases until they have been initialized. A new schedule becomes the current schedule which means that the currently accessed databases are specific to that schedule and that the comments and feedback are also specific to that schedule.
When the user clicks the Open button, a dialog appears as shown below
Figure 2.10.1 - 1
The user can navigate through directories until the desired schedule is found. Then the user clicks open to load the file. When a schedule is opened from a saved file, the name of the schedule is synonymous with its root filename. The root filename is the name of the file, less any leading file path and less any filename extension. For example, the name of the schedulestored in the file "/users/home/dcollins/.Schedulerl/DepartmentSchedule.sch" is "DepartmentSchedule". The Scheduler provides no command to change the name of a schedule independent from its filename. In particular, the only way the user can name an unnamed schedule is to save it to a file.
The `New' and `Open' commands are always enabled in the file menu. The following is a summary of the when the `Open' button is enabled in the file-open dialog:
Zero or more schedules can be opened at a time. The user simply selects which one to be the current schedule. Since `New' and `Open' are always enabled, the user may execute these commands at any time while the scheduler is running. This means that the user can have an unbounded number of schedules open. If taken to an extreme, this could conceivably cause resource problems in some operating environments, but we assume that there is ample work space and that the user is not going to have an infinite number schedules open.
2.10.1.3 Close and Close All Commands
The `Close' and `Close All' commands are enabled in the `File Menu' if there is at least one open schedule, disabled otherwise. `Close' applies to the current schedule; `Close All' applies to all open schedule.
When the user selects the `Close' command, the system performs the following pre-close steps for the schedule to be closed, i.e., the current schedule:
Once these steps are completed satisfactorily, the system proceeds to perform the close operation. Details follow.
For the first pre-close step, the system checks if the current schedule has any unsaved changes. The precise definition of an unsaved change is given in 2.10.1.4 If there are one or more unsaved changes, the system displays the dialog shown in Figure 2.10.1 - 2.
Figure 2.10.1 - 2
If the user presses `Yes', the system proceeds as follows:
If the schedule to be closed has no unsaved changes, the system proceeds to the next pre-close step, without displaying the offer-to-save dialog. Schedules with no unsaved changes are those that have been saved prior to close.
For the second pre-close step, the system checks if there are any pending edits in schedule-specific, non-modal editing dialogs for the schedule to be closed. To avoid complications of which dialog would prevent the user from exiting, for version 1 all dialogs have been made so that while the dialog is open, the user cannot edit other parts of the schedule or select other commands in the scheduler program. This ensures that no dialogs are open when the close menu button is selected.
Closing all or the last schedule does not close the scheduler program, but leaves the scheduler vacant with simply the file bar as described in Section 2.1
2.10.1.4 Save, Save As and Save All Commands
A new schedule is not associated with a file until it is saved for the first time. For new not-yet-saved schedules, the `Save' and `Save As' commands have exactly the same effect. When the user selects either of these commands for a not-yet-saved schedule, the system displays the dialog shown in Figure 2.10.1 - 3.
Figure 2.10.1 - 3
The system does not pre-enter "unnamed" in the `File' field, to discourage the user from naming a schedule "unnamed". The system does not however prevent a recalcitrant user from doing so.
As in the file-open dialog, the user may navigate to another directory by selecting from the `Look In' pulldown list and by selecting directory names in the scrollable list. To save to a file, the user types its name in the `File' field. The Save button is always active even if nothing has been typed in. If nothing was typed then the file is saved as 'UnnamedX' where X is equal to the number of unnamed files minus one. The first unnamed file has no appended X value.
When the user presses `Save', the system saves the entire contents of the schedule onto the named file. All scheduled classes and references to current databases are saved. After completing the save, the system removes the save dialog from the screen. If the user enters the name of an existing schedule file and presses `Save', the system asks for overwrite confirmation, as described below.
When the current schedule is already associated with a file, the `Save' and `Save As' commands differ. The `Save' command is enabled whenever the current schedule is associated with a file, and the schedule has unsaved changes. A schedule has unsaved changes when the user has scheduled any classes or edited any preferences.
If the user undoes any of these actions such that the state of the scheule returns to the same state as most recently saved, then the schedule no longer has unsaved changes. The "state" of the schedule is defined as the values of all scheduled classes and preferences. It is noteworthy that the definition of unsaved change includes any and all actions that change scheduled classes or preferences .When the user selects the enabled `Save' command in the `File' menu, the system saves the scheduled items and settings for the current schedule on the file associated with the schedule.
The `Save As' command is enabled in the `File' menu always. `Save As' is enabled whether or not the current schedule has unsaved changes. When the user selects `Save As' for a new schedule, the system displays the dialog shown in Figure 2.10.1 - 3 and the system actions are those described for that figure.
When the user executes `Save As' to an existing schedule file, the system displays the warning dialog shown in Figure 2.10.1 - 4.
Figure 2.10.1 - 4
If the user presses `Yes', the system proceeds with the save, fully overwriting the previous contents of the file. The states of the original and saved-to files are as described above for when `Save As' saves to a new file. The system also changes the name of the current schedule in the same way as for `Save As' to a new file. If the user presses `Cancel' the system does not perform the save, returning to the `Save As' dialog where the user can enter a different file name. In either case, the system removes the overwrite warning dialog.
The user can type or select the schedule's current name in the save-as dialog, although this defeats the ostensible purpose of the `Save As' command. If the user does so and presses `OK', the system saves the calendar onto the file with which is currently associated, in the same manner as if the user had executed the `Save' command.
When the user selects `Save All' in the `File' menu, the system executes a `Save' for all schedules with unsaved changes. If any of the schedules are not yet saved to a file, and the user presses `Cancel' in the save-new-schedule dialog Figure 2.10.1 - 3, the system cancels the save for that schedule only.
The following is a summary of the enabled/disabled states of the save commands:
`Save' and `Save As' are disabled otherwise.
Printing from the scheduler is very limited. The user is only able to print the List view. If the List view is not open the scheduler will still print the list view. The schedule comes out of the printer with default margins on every side of the page of one inch. At the top of each new page, the List titles of Course Number, Room, Building, etc. are relisted. When the user selects Print the dialog appears as below
Figure 2.10.1 - 5
The user selects the printer from the list of currently installed printers on the machine and then clicks print to print the schedule. To print multiple copies, the print command must be run multiple times.
When the user selects the `Exit' command in the `File' menu, the system begins the exiting process by executing the `Close All' command. The associated processing for `Close All' ensues, including any necessary user interaction through the warning dialogs. This is described previously. If the user responds at any point such that the `Close All' is canceled for all remaining calendars, the `Exit' operation is also thereby canceled.
The scheduler is closed if the 'Close All' command completes.
Prev: [None] | Next: Edit Commands | Up: File and Edit Commands | Top: index
