•Parse the Returned Strings thoroughly. Don’t assume anything about the next response from the Server to your program and look only for the partial string such as the ID only. Parse the string returned completely, and be sure you are examining every possibility. Failure to do so is a common mistake.
•Plan for expansion. You may start small (1 Terminal) but try to create an application that will allow for easy expansion.
•Use the Test Program. The test program can at least allow you to see how the system functions and whether you can anticipate any
•Study the Demo Programs. Demo programs are included for examples of how to use the ActiveX tool provided.
Failure Planning
Hardware Failures
Let’s assume that each part of the system has failed. How are you going to know what has happened and how are you going to recover?
•The most frequent failures are at the Terminal level. If a Terminal has a hardware failure, it will not be able to SIGN OUT. It is possible for the Terminal operator to press the ON/OFF key or the F1 key by accident, forcing the Terminal to SIGN OUT - sometimes in the middle of a transaction. This happens at
•Keep in mind that if a Terminal has SIGNED OUT in
Operator Errors
•Plan on your operator walking out of range and going to lunch in the middle of a transaction. What do you do with the data you do have, and where are you going to start up again?
•Let’s say your operator is SIGNED ON and decides it’s time to take a break. Instead of pressing the F1 key to SIGN OUT, he presses the OFF key. Pressing the OFF key is OK (it will SIGN him OUT) but there is a delay until the SIGN OUT is acknowledged. Because of the delay, the operator might think he didn’t press the key hard enough and press it again - this time actually powering down the Terminal before the SIGN OUT was complete. If this happens, you need to plan to
