Worth Data 802 RF Credit Card Machine User Manual


 
6-2
Methods are how you initiate communication with the WD802Term object.
You can request that a prompt be sent to a terminal, map a terminal ID to an
IP address, and a variety of other services.
Events are how the WD802Term object initiates communication with your
application. You write "event handlers" in your program to respond that
respond appropriately when WD802Term "fires" an event that activates its
associated event handler. Examples are OnTermSignIn and OnTermData.
Creation of the source code "shell" for an event handler is generally handled
by your development environment (IDE for Integrated Development
Environment). For example, in Delphi, simply double click in an event field
in the Object Inspector; or in VB, from the source code window, select the
Object from the pull down list at the top left and then click on the desired
event in the Procedures pull down list at the top right.
You will notice that the IDE creates a "skeleton" function (or procedure or
sub) in source code that will include any parameters required to retrieve the
data delivered to the event handler by the WD802Term object.
It is your job to add functionality to the skeleton event handler that is
relevant to your application. It is important to remember to keep event
handlers short and efficient. Do not make method calls to WD802Term
from within a WD802Term event handler. Instead set up a state
management and polling or threading scheme as outlined below.
Signing In, Data Structures, Transactions, and State
Management
When a terminal SIGNS ON, it sends a signal to your application via the
WD802Term object, which fires the OnTermSignIn event. When the event
fires, the terminal has already been assigned an ID number by WD802Term
and this ID number is passed to your application in the event handler.
Once it has signed in, the terminal is now waiting for your application to
make a call to one of WD802Term's methods that sends a prompt to the
terminal. Keep in mind that it is important to keep event handlers short and
to try to avoid making method calls from inside an event handler. This
brings us to transactions, state management, and data structures
Generally, you will have some kind of transaction process that you will
define. Typically a transaction would be defined by a series of prompts and
the data returned in response to the prompts.
Here is an example of a series of prompts that represent a transaction. When
a transaction is completed, it repeats as controlled by the host application
Go to location XX
Press enter when ready: