CLACom FAQ's - Sending & Receiving Data

CLACom includes a Sample Program called GTERM. In addition to an already compiled program, you should find the source Applications for CFW 4 (ABC and Standard) and CFW 5 (ABC and Standard) in your CLACom installation directory. In the Public Files area of our Web Site you will also find many other example programs.

The CLACom Application Files contain a Wealth of Information. Nearly every line of Source Code that was written to interface CLACom with the application is commented with meaningful explanations. Most of the Communications Functionality in the GTERM Program comes from using the Templates (DialNumber, Terminal, AnswerPhone, etc).

It is difficult to offer Step By Step Instructions, since we have no idea what it is you wish to accomplish. You may wish to Dial a Number, Connect, and then send/receive a Credit Card authorization. Others may wish to Connect, and then send/receive several files. Some need to use the Serial Port to control a Robotic device (no modem attached, and precise control over the data stream is necessary).

The Basic Steps are as follows:

SetPort()
InitPort()
..... Your Code goes here
ResetPort()

We cannot possibly tell you what to do when it comes time to insert your own code to deal with the Serial Port Data Stream. All we can do is offer advice and suggestions.

If you need Terminal Emulation capabilities, by all means start with the GTERM Sample program as the "skeleton". Change the things you do not like and add your own features. All that we require is that you remove our Logo and Name from the About Box and Splash Screen.

If you need to send and receive files automatically, download the Client/Server Sample Application that is posted in the Software Library. It is fully commented and very easy to change to suit your own needs.

If you need any help implementing CLACom with your Clarion Application, need advice, want to know if it is better to use ComGetc() or ComGetd(), can't quite get that Modem to Dial, or whatever problem you may be having, please feel free to send an email to supportgapdev [dot] com, and we will offer all the help we can. We would prefer E-Mail as opposed to Voice Calls on such issues because that allows us to send you snippets of code, and gives others an opportunity to share in the exchange of information.

To simultaneously monitor and process data on 2 or more Serial Ports, you need to use the Timer Event and process data in "chunks". Both of your "started" Procedures need to have a Window associated with them. This is because you need to do your work inside of an Accept Loop. The Windows, themselves, can be hidden if you have no need to display data.

In order for other Threads to run, you must CYCLE the Accept Loop. You do this by "falling through" to the End of the Accept Loop or by issuing an explicit Cycle command. If you need to import 100 or 1000 records that were received over the Serial Port, into a Database, no other Thread will run until you are finished importing the records. In 16 Bit Windows, no other Windows Program will run until you are finished.

The following is an Example of how things were done in DOS programs:

Set(MyDataBase)

Loop
   Next(MyDataBase)

   If ErrorCode()
     Break
   End
End

If there are 1000 records to process, the Loop would not terminate until an Error occurs or EOF is reached. If it takes 10 minutes to process the records, nobody cared, because your program is the only program running.

In Windows, things are quite a bit different. Your program most likely is not the only program running. Remember, you've got Windows itself running, perhaps a Clock, and perhaps a Word Processing program. If you use the above Loop in a Windows Program, and it takes 10 minutes to process the records, your Program will be non-responsive to Windows Events for 10 minutes. Move another Window on top of your Application, and then move the other Window away, and your Application will be left with a "hole" on top of it, because it is not responding to a Paint Message that Windows sends to your program to tell it to repaint itself.

Under Windows, a better approach would be to process the Records in a Timer Event. Example:

Open Window Event Handling

Set(MyDataBase)

Timer Event Handling

Loop 10 Times
   Next(MyDataBase)

   If ErrorCode()
     Break
   End
End

Note that you prepare the Data File for processing when the Window first opens. You then process 10 records at a time in the Timer Event. Since Timer Events have lower priority than other Windows Events, your Program will be responsive to the User and to Events generated outside of itself (i.e., Windows telling your Program to re-paint itself).

If you break your processing of Serial Port data into "chunks", and use the Timer Event to process the data, you will be able to simultaneously handle 2 or more Serial Ports at the same time, without too much degradation. It should be noted that you can't just take the DOS version of the Loop and put it in a Windows Timer Event. Because the Accept Loop needs to Cycle to allow other Threads to run, if it takes 10 minutes to process data in a Timer Event, the Accept Loop will not cycle until that 10 minutes is up, and you will effectively lock out other threads.