Take a look at the RFC (http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1055.html) PROTOCOL The SLIP protocol defines two special characters: END and ESC. END is octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be confused with the ASCII ESCape character; for the purposes of this discussion, ESC will indicate the SLIP ESC character. To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and octal 334 (decimal 220) is sent instead. If it the same as an ESC character, an two byte sequence of ESC and octal 335 (decimal 221) is sent instead. When the last byte in the packet has been sent, an END character is then transmitted. Are you implementing this on Windows ? I would recommend creating layers ( translated as C++ Classes ) Transport Layer Slip Layer You will have to have two threads that do the job of sending and receiving data . In other words the job of the SLIP layer is to send packets by adding SLIP characters and the reverse ( receive packets and then sense the SLIP characters , then strip out these characters and notify the top layer that data has come ) I would suggest implementing callbacks so that the layers above can be notified upon data reception / successful sending of data / error conditions Additionally you can add CRC checking in the transport layer The transport layer can contain additionals such as retries , retry counts etc As for the low level IO , use the standard serial port API's such as PurgeCOmm and readfile and writefile Engineering is the effort !

Thank you very much for your response. I cannot go for .Net. I must implement it only in VB. Can you give me more details on how to make the GUI responsive while running a long task. Thanx and Regards, Sushma

In that case, don't worry about the USB cable being plugged in. Since your app is communicating over Serial ports only, no matter what the cable medium is, your app doesn't change if the cable changes. So why are you complicating your code over something your code doesn't care about in the first place? There is nothing that maps COM ports to what cable they're on, if they are simulated, or implemented on hardware other than actual Serial ports. The driver you installed for the cable puts up the illusion of a Serial port, then quietly sits behind it, translating between serial comm and USB. If the USB cable can be on any COM port, don't mess with USB. Just go through the COM ports and try to communicate with your target app on each one. If you get a response, you've found the port your need. If not, you'll have to rely on the user to tell you which port to use. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Hi Dave, Thanks so much for all ur suggestions. I have baught a USB cable which comes along with a driver.The driver after installed creates a COM port for USB port as soon as the USB cable is plugged in.Hence i can access the USB port just like a com port. It made my job very easy! Thanx again, Sushma

Read the official VS2005 help it will answer your question. You can also read the .NET FW system.threading.thread class documentation since contains code samples. It's really basic.

Are you sure your looking at the right property. RecordCount should and is Read-Only for a reason. What are you attempting to accomplish by changing the RecordCount property?

Dr. Newcomer is a SME on device drivers. See his book here. "Take only what you need and leave the land as you found it." - Native American Proverb