Handheld Terminal Software
User's Manual, version: 3.1 / material no.: 57448 93
© KEBA 2006
Since the values of this dialog must already be available for the initialization
of the port, the dialog is held by the SerCp class as, from a design point of
view, it fits best here.
SerCp
This class forms a level of abstraction above the CP001 driver and should
simplify communication with the control for the application.
The Constructor loads the SerCp001.dll. Moreover, function pointers to the
method of the SerCp001.dll that is used are immediately created and the
Callback function that is used for reading out values to the control, is hung
up. The Destructor closes the port and releases the Dll. This class provides
a "simplified" interface for communicating with the control.
Ketop
This class also forms a level of abstraction above the KetopAPI and, thus,
should simplify access to it. It provides a somewhat "simplified" interface to
the outside world.
The Constructor loads the KetopAPI.dll. Also in this case, function pointers
to the required method are retrieved (however, in a somewhat different
manner than in the SerCp class) and a Callback function, which is called
automatically by the KetopAPI during modification, is hung up.
Procedure using the example of the test tool
The Init of the TestToolApp class firstly initializes the member variable
(mSerCp) of the SerCp class that sees to the configuration of the driver. At
the same time, the configuration dialog (SerConfigDlg) is called, the en-
tered values are stored and, with them, the port to the control is opened
and configured. The TestToolDialog is then called (in the TestToolApp
class) and displayed on the screen. This starts with the start of a timer that
issues a cyclical write command with the read command to the control.
(Without the timer, the application would never be informed about modifica-
tions to the control because, in this test example, the control never be-
comes active by itself.)
To Next Page
Loading...