>I really appreciate your help! I am getting there slowly. A few more questions.
>If I am doing this connection and text data retreival programmatically, 1.Wouldn't the MyWrapper.prg get overwritten each time the code ran?

That's why, as I pointed out, you only use ExportEvents once (or no times if you already know the event model) once to grab the skeleton, and then after building your custom class, only use the BindEvents method of VFPCOM to tie it to the COM object.

>2. I am at a dilemma on where this code goes for (the oMSCOMM & oVFPCOM),
> is the define class DMSCommEvents put in the init?

Just like any non-visual class, it's a .PRG file that needs to be available at runtime - make a procedure file of it and before doing the CREATEOBJ() for the wrapper, make sure that you make it available (SET PROCEDURE TO...ADDITIVE works). The wrapper isn't a part of oMSCOMM, or oVFPCOM; oVFPCOM is used to tie instances of the COM object to the wrapper class instance.

>There is an article at support.microsoft.com/support/kb/articles/q140/5/25.asp that uses the MSComm32.ocx for a serial connection. Again, I get the portopen property to true, but the CommEvent buffer is empty.
>
>Maybe I am defining my classes wrong. Should I be writing in my main.prg
>or the init of a form?
>DEFINE CLASS ComConn CUSTOM OLEPUBLIC
>PROCEDURE OnComm
>with this
> .commport=1
> .settings="9600,e,7,1"
> .portopen=.t.
> .rthreshold=1
>endwith
>

This means that every time you have an OnCOmm event, you reset the port. The OnComm event assumes that you've already opened the comm port, and is there to tell you that something has happened - you now need to examine the event properties to see what event occurred and do something.

I think you'd be better off dropping the idea of interrupt-driven I/O for this - you have a very narrow focus and don't seem to need other things to go on while the serial transfer occurs.

>if this.CommEvent>2
> thisform.pBuffer=thisform.pBuffer+this.input
>endif
>endproc
>
>Then hold do I get the buffer to text file..mytext.dat, in either case?
>

Umm, open a file for low-level output before you start, and use FPUTS()/FWRITE(), or accumulate to a string and use STRTOFILE() when finished, or any of a couple of dozen other ways to write to a file inside VFP. There's nothing mysterious going on here - you're writing a string to a file.

>As you can see "I am going to figure this out". I apprecioate your patience.
>Thanks, Chuck