Design and Development of a Diagnostics Client for a Beam Loss ...

Design and Development of a Diagnostics Client for a Beam Loss Measurement System at CERN
The last and very important group of settings is the storage group. It consists of a button,
a small text field and a checkbox. It is shown in Figure 20. A user should utilize the check
box to select whether or not to save the incoming data into binary files. The path used for
the logging process is displayed in the text field. This path is specified by the user, who
must press the directory button, so that a pop-up window with a Folder-Chooser appears
for path selection.
All of the aforementioned parameters should be set before starting a new acquisition ses-
sion. In the actions group of the GUI the Start and Stop buttons exist. A control check
of the values of the parameters should be initiated before establishing a connection with
the BLEDP server. If a parameter is wrongfully or not set and the user presses the Start
button, an error pop-up window appears.
Most of the important parameters have default values, in case it is the first time that the
client executes on a computer. If it has been executed more than once on the same
computer, then the application “remembers” the settings of the last time. This feature is
achieved with the help of a class named PersonalSettingsManager. This class makes use
of a HashMap and a binary file, where the latest values of many Swing components are
stored. The directory where this binary file is stored, depends on the operating system on
which the client is running. Furthermore, it is obvious that different binary files are stored
for different users of the client.
4.4.2.1 Design implementation of the online interface
In general, the online panel is handled by a class named OnlineDataViewerGUI. This class
creates and handles all the panels and the components inside them using several swing
layout managers, i.e. FlowLayout, GridLayout, GridBagLayout and BorderLayout. It also
contains several action listeners and event-handling methods for the different components
and manages every control check of the parameter values before initiating the communi-
cation with the embedded server. Also, the main method of the application is part of this
class.
The Swing event handling code runs on a special thread known as the event dispatch
thread (EDT). Most code that invokes Swing methods also runs on this thread. This is nec-
essary because most Swing objects methods are not “thread safe”, so invoking them from
multiple threads risks thread interference or memory consistency errors. It’s useful to think
of the code running on the event dispatch thread as a series of short tasks. Most tasks are
invocations of event-handling methods, such as ActionListener.actionPerformed. Other
tasks can be scheduled by application code, using invokeLater or invokeAndWait. Tasks
on the event dispatch thread must finish quickly; if they don’t, unhandled events back up
and the user interface becomes unresponsive. [12] In our case, we need to execute a
long-running task, which is the communication with the server and then data acquisition,
processing, logging and plotting. We have to use a background worker thread for that
Emmanouil I. Angelogiannopoulos 34