DIALOG BOXES, MENU, AND PROGRESS WINDOW
All dialog box and menu design templates are found in the resource.rc
file. As mentioned before, all menu-related messages get sent immediately to the
application's message queue and are processed by the SRMS service's message handler
function, WndProc(). However, dialog boxes used in this application operate
slightly differently. All dialogs are modeless dialog boxes, which means that Win32's CreateDialog()
function returns immediately after creating the box and does not wait for the user to
close the box before returning. Modeless dialogs best suit the SRMS service because the
application cannot wait for a dialog box to close before proceeding. Although modeless
dialogs incur a little bit more overhead than modal dialogs, their functionality in this
situation far outweighs the overhead. [The only negative aspect about modeless dialogs
that was found is that a user cannot close a dialog with the escape or return keys as they
can with modal boxes. It is a slight inconvenience that is overcome by using the mouse and
one that was found insignificant enough so as to not pursue a remedy.]
There are four dialog boxes used in the SRMS service. All four were created with
Visual Studio's resource editor and their names (as referred to in the resource.rc) file
are as follows: "Remove Threads Dialog", "View Threads Dialog",
"Set Priority Dialog", and "System Task Dialog". As part of the
overhead mentioned above, messages destined for modeless dialogs need to be dispatched by
Win32's IsDialogMessage() function, not WndProc(). Therefore,
there are four global handle objects defined in mainapp.c that refer to each
of the dialogs: hDlgRemoveThreads, hDlgViewThreads, hDlgSystemTask,
hDlgSetPriority. When a message is received by the service's main message
loop, IsDialogMessage() tests the message to see if it is destined for a
particular dialog box. If so, then WndProc() gets bypassed and the default
dialog box callback routine processes the message. Each dialog box has its own callback
routine found in dialogs.c which is assigned to the dialog when it was
created by the CreateDialog() function.
The "View Threads Dialog" lists only those threads that are registered as
real-time tasks and actively being scheduled by the SRMS scheduler (i.e., all tasks in the
task_list). This dialog can be viewed from the SRMS service GUI by selecting
"Active Registered Tasks" from the View menu. When a user selects a task
from the list box of displaying all active tasks, the dialog's fields fill with relevant
information about the task's priority, importance, estimated and delivered QoS, met/missed
deadline statistics, etc. This dialog is not automatically updated to reflect the current
state of the system, although the its fields are updated when an item in the task list box
is newly selected. Only the list of active tasks is automatically updated when a
task enters or leaves the system.
The "Remove Threads Dialog" displays a list of all registered tasks in the
system, regardless of whether they are waiting for QoS admission or if they are actively
being scheduled. From this dialog, a user can select one task at a time to remove from the
SRMS system. When a task is marked for removal, the dialog callback routine sends the SRMS
scheduler a WM_UnregisterRTMsg message with the task's id as the LPARAM value
of the message. The arrival of that message causes the scheduler to wake from its
wait state and immediately process the removal of the task from the SRMS system. The
scheduler then calls the handle_unregister_task() function to handle the details.
That function returns the task thread to the priority level it was at before it became an
active real-time thread. It then unregisters the task by removing it from the
system's task list (if applicable) and placing it in the unregistered task list.
The unregistered task list is only used to keep track of the execution histories of tasks after they leave the
system. Also, the QoS admission thread is recreated
to recompute the task set's quality of service values and to check whether any waiting
tasks can enter as a result of the freed resources.
The "System Task Dialog" registers or unregisters the NT system task thread. It is also here that a user can specify the percent utilization that the system task should receive and the length in milliseconds of its period.
Finally, the "Set Priority Dialog" allows the user to modify the priority level and priority class of the SRMS scheduler, message handler, and the task threads. These settings are only in effect when the SRMS service is in its active (or started) state.
To keep a record of the application's progress, there is a progress window that is
updated periodically to give the user more insight into the system. The window is opened
and closed by selecting "Progress Window" under the View menu of the service's
GUI. Upon opening the window, the application creates a new child window and assigns the
global handle hProgressIndicator found in mainapp.c to reference
it. It also displays all messages that are already in the SRMS log (the log is referenced
by the pointer srms_log, which is globally defined in mainapp.c).
The system stores all entries in the log whether or not the progress window is active.
Whenever it becomes active, all entries in the log get displayed. Essentially, the log is
simply a singly-linked list of srms_log_entry_structs (defined in srms.h),
which is just a linked-list of strings. The function update_log() found in mainapp.c
is used throughout the code to add entries to the log. It takes a string parameter
which it copies to a srms_log_entry_struct, and that gets added to the end of
the srms_log. Once the entry is added to the log, the string gets added to
the progress window, and ultimately displayed assuming that the window is open.