>Ed
>I finally got the wrapper class after I realized I had not downloaded vfpcom.dll. The black box data is ascII. I set the handshake to 2,(RTS/CTS (Request To Send/Clear To Send)). When I issue omscomm.Output = "phoenix.dat", I would think that would put the data string in a buffer that I somehow put into a readable text file.
>Shouldn't I be able to issue some equivalent to FOPEN() or have I already done that. My brain is mush! If the port is open, shouldn't I be able to extract the text with a few commands and append to a dbf?
>
>This is what I have done.
> * this creates the mscomm object that opens the serial port
> oVFPCom = createobject("vfpcom.comutil")
> omscomm=createobj('mscommlib.mscomm')
> omscomm.PortOpen=.t.&& should this be in the oncomm event?

No, this is the FOPEN(), but before you do a PortOpen, it would help to set the port that you're configuring; in your case:

oMSComm.CommPort = 1

to open COM1:; change the number as needed.

> *create wrapper class to put code for custom method oncomm
> oVFPCom.exportevents(omscomm,"C:\zzapps\Dev60Lib\DOT SPS\Text\phoenix.prg")

No, you'd better have done this well in advance of the actual runtime. This simply creates the shell that you can use to build the class to handle the OnComm event. You need to have added the necessary code to handle the various events signalled by OnComm. ExportEvents is usually issued once, during the development phase of your app, to create the class shell that you then modify and use at runtime.

> * I believe data should be in buffer - how to put there & retreive??
>

Your write data to a port by setting the Output property of the COMM device:

oMSComm.Output = "Four score and seven seconds ago, this progrma crashed!!" +CHR(13) + CHR(10)

You read from a port by examining the Input property. If you set the InputLength property to 0, you will get the complete content of the input buffer; values other than 0 read up to the number of characters specified.

oMSComm.InputLen = 0
cBlackBoxResponse = oMSComm.Input

If you're willing to have your app sit and continuously check for input and can check to see if CTS is ready before sending more stuff to the box, there's no need for VFPCom. The MSCommlib.MSComm has an event, OnComm, which is fired every time a reportable comm status event occurs; by using an event-driven (interrupt-driven) approach, you can have other things going on in your app without missing time-critical events. Poling is simpler, but eats processor time that might be able to be used for other things.

>I am sorry, I guess I do know as much about this text extraction as I thought.