Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!tank!oddjob!rfl
From: rfl@oddjob.uchicago.edu (Bob Loewenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serial question
Message-ID: <5807@tank.uchicago.edu>
Date: 13 Oct 89 14:58:49 GMT
References: <5727@tank.uchicago.edu> <531@sunfs3.camex.uucp>
Sender: news@tank.uchicago.edu
Reply-To: rfl@oddjob.uchicago.edu (Bob Loewenstein)
Organization: U of Chicago - Astronomy & Astrophysics
Lines: 19


Kent Borg points out:
> The bad news is I don't know how to tell whether a program in the
> background has been messing with the serial port.  The details for
> sharing serial ports are not nice.  Might check into the
> Communications Toolbox, it might offer some help.

This is the essence of the problem now. My program is multifinder aware,
and I can respond to resume/suspend events. However, I have no way to
know if another program or da has messed with the serial port. If one has,
I have lost any data that may have been coming in the background, and upon
a resume event I can at least reset the port and its buffer. But if the 
port is still mine, I don't want to mess with it myself and then lose any
current transmissions. Basically the question is now:

How do you know if the port is still yours. I can find no call that tells
me, for instance, the size of the internal buffer (I could compare to see
if it's = to my buffer size), or the address of that buffer, or the
configuration of the port for comparison.