Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!husc6!sunfs3!kent
From: kent@sunfs3.camex.uucp (Kent Borg)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serial question
Message-ID: <531@sunfs3.camex.uucp>
Date: 11 Oct 89 19:55:49 GMT
References: <5727@tank.uchicago.edu>
Reply-To: kent@lloyd.UUCP (Kent Borg)
Organization: Camex, Inc., Boston, Mass USA
Lines: 36

In article <5727@tank.uchicago.edu> rfl@oddjob.UChicago.EDU (Bob Loewenstein) writes:
>
>I have a program where I use the serial driver at 19200 baud. I
>set the size of the internal buffer to a large block so that I don't
>miss any transmissions while I'm not reading the port (64 bytes, the
>default, is too small). My problem is this: If someone using the program
>decides to open up some terminal emulator desk accessory, or switches
>via multifinder to another program that wants the port, when they
>switch back to my application, always my buffer is no longer used and
>the default is back; sometimes it screws things up altogether and
>causes a bomb.
>
>How can I manage the port for these user switches? If I knew when they
>returned to my program, I could reinitialize the port. 
>
>Any comments would be appreciated.

If your program is MultiFinder aware, you will get suspend and resume
events whenever you are switched in or out.

If you do not set your MultiFinder aware bit, MultiFinder will pretend
a DA is being used as a way to force you to convert your private scrap
to a desk scrap.

Either way, it is possible to tell from within your event loop whether
another program has been in the foreground.

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.

-- 
Kent Borg				"Then again I could be foolish 
kent@lloyd.uucp				 not to quit while I'm ahead..."
or					     -from Evita (sung by Juan Peron)
...!husc6!lloyd!kent