
                      ST REPORT WEEKLY ONLINE MAGAZINE
                            Monday, SEPT. 12, 1988
                               Vol II  No. 52
                                ===========

            APEInc., P.O.  BOX 74,  Middlesex, N.J.  08846-0074

  PUBLISHER                                              GENERAL MANAGER
  Ron Kovacs                                               R.F.Mariano

          =======================================================

                     ST REPORT EDITOR: Thomas Rex Reade

                PO Box 6672 Jacksonville, Florida. 32236-6672

                        Headquarters Bulletin Boards

 ST Report North                                         ST Report South
  201-343-1426                                             904-786-4176

                   ------------------------------------
 ST Report Central                                       ST Report West
  216-784-0574                                             916-962-2566
                                 CONTENTS
                                 ========
> From the Editor's Desk..............> SHADOW - A full review............
> GEnie Conference....................> DO IT TO IT.......................
> ST REPORT CONFIDENTIAL..............> Pro GEM Windows #3................
                                  MOUSECARE

=========================================================================
EXCLUSIVELY ON:       COMP-U-SERVE    ~    GENIE    ~    DELPHI
=========================================================================


From the Editor's Desk.......

As we approach the Fall Season (Sept. 22), let's take a look at what we 
have to be thankful for.....health, happiness, a wonderful country we 
live in and...ATARI!  We see where Sig Hartmann has taken the time to 
prove to all that Atari is not ALL double talk as SOME of it's folks 
would allow us to believe...(See ST REPORT CONFIDENTIAL)

Hats OFF to Mr. Sig Hartmann! Exec. Vice President Atari Corp. 

More and more we hear about the wonderful things happening in the European
market as far as the ST is concerned.  For us in this country the only
thing that means is software....now for some food for thought, what about
the US developers who by Atari's design will be light years behind
European developers when the US market finally takes effect..a future
headline..."US developers entreat Congress to tax import software heavily
to balance the lopsided US market" is it possible?  Maybe.

The big thing is Atari is alive and well.  That is the most important 
factor there is before us.  Why?  Look at this, who else has the
the 68000 doing the things it does in the ST line?  Sure, there is the
68030 add on coming soon..but that only builds the level of proficiency of
the ST Line.  We as users must encourage Atari to fine tune the OS and
other areas in which we use the ST.  Having Atari pay attention to detail
will indeed accomplish more than all the heavy redesigning could ever do
for the same investment cost.

The Aura of the Las Vegas Comdex Show is beginning to overpower the normal
flow of information, however, we will, over the course of the next few 
weeks be seeing more information about next year and what is in store as 
a result of the Comdex revelations.  It certainly appears Atari is on the
right track, let's wait and see.....

                                          Rex.......




**************************************************************************
  NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE

                          FOR A LIMITED TIME ONLY

    COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLINE TIME

                              to the Readers

                   ST REPORT ONLINE ELECTRONIC MAGAZINE

                         NEW USERS SIGN UP TODAY!

            Call any of the St Report  Official BBS numbers 
                    (Listed at the top of ST REPORT)
                                    or
            Leave E-mail to St Report, Ron Kovacs or Rex Reade

            Be sure to include your full mailing address so your 
              Compuserve kit can be immediately mailed to you!

                            Expires 09-30-88

  NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE
**************************************************************************



                        SPECIAL SUPRA MODEM OFFER!!!
                        ============================


CompuServe's Atari Forums have made very special arrangements with 
Paramount Products Inc. to offer the members of our forums the chance to 
upgrade your system to 2400 baud service at a very special price.  

For a limited time, CompuServe subscribers may purchase the 

             SUPRA CORP. 2400 baud Hayes-compatible modem 
           for the very **LOW** price of just $139.95 !!!!! 

These are brand new, not reconditioned units, with the full SUPRA CORP. 
warranty.  The SUPRA MODEM uses the Hayes Smartmodem 'AT' command set and
operates at 300-1200-2400 baud.  It's an outboard unit (not an internal 
plug-in card) allowing ease of transfer to other computers.  
Connection is thru the standard RS-232 interface. (Just plug it into the 
back of your ATARI ST).

       To take advantage of this special offer, Phone the 800 number 
       listed below or write to:

                        Paramount Products Inc.
                        1405 S.E. Pacific Blvd.
                        Albany, Oregon   97321

         *****          Phone orders: (800)444-4061        *****

     Price:    $139.95 + shipping
     UPS ground:     add $4.00
     UPS Blue label: add $8.00
     C.O.D.:         add $2.25

  MasterCard or VISA accepted Orders will be shipped the next business day

   If you've been accessing CompuServe at 1200 baud, this is a  great way
to lower your total online bill since CIS does *NOT*  charge a premium for
2400 baud access.  (You can get the same amount of information or download
the same amount of programs in approximately 1/2 the time as 1200 baud 
users!) This modem will PAY FOR ITSELF in just a few sessions.



--------------------------------------------------------------------------



                               - SHADOW -
                               ==========


by Dave St. Martin

GEnie:  ST.MARTIN
CIS:  74156,31 


It was the typical conversation that evolves any time two owners of 
differing computers get to talking about how much better their 
particular machine is when compared to the other guy's.  This time 
it was the archrival, an Amiga owner.  Eventually the topic of 
multitasking popped up.  I remarked, "Why in the world do you guys 
always rave about multitasking?  The fact is, on a personal 
computer you really only need to do one thing at a time.  The odd 
occasions that require two applications running at the same time 
simply don't justify it, and besides, it slows things down... "  
He replied, "How much computer time have you wasted waiting on 
those long downloads lately?".  I brushed the comment off.  That 
was a year ago.  Since that time I've sat many times, watching the 
block numbers increment as FLASH! grabbed yet another long file.  
Each time the thought was the same "It sure would be nice to be 
able to do something else with my only machine - the time I get to 
spend on this thing is too short as it is......  Maybe Mr. Amoeba 
was right....".  Times have changed - I'm doing an upload as I 
write this review.

Not long ago while perusing The Catalog, ANTIC Software's listing 
of titles, I stumbled onto a new product.  The ad claimed 
SHADOW would do background file transfers on the ST allowing the 
use of most other GEM applications simultaneously.  I decided that 
SHADOW might be worth checking out.

When the package with SHADOW arrived I was still a disbeliever.  
I did something I rarely do - I read the manual.  The manual was 
detailed, but easy to follow and explained the various SHADOW 
configurations with reasonable clarity.  SHADOW, it claimed could 
be run from almost any GEM based program by installing it as a 
desk accessory.  In this configuration SHADOW emulates a DEC VT-52 
terminal whenever the desk accessory is activated.  A walk-through 
of the desk accessory version is perhaps the best approach....

                            SETTING UP
                            ----------

There are actually two parts to SHADOW.  The first is the main 
program (.PRG) file which should be placed in an AUTO folder, the 
second is the ".ACC" loader that accesses the main program.  Once 
the accessory has been activated the user is presented with a 
dialog box containing 15 buttons. There are six transfer protocols 
presented including three XMODEM styles, Y-MODEM Batch, Compuserve 
B-Protocol, and straight ASCII.  Of the XMODEM varieties CRC, 
Checksum, and 1-K blocks are supported.  At this point you'd 
select the protocol you intend to use.  Additionally, you would 
need to decide whether you were going to send or receive, and 
which baud rate to use.  Defaults can be set to allow your 
configuration to your typical set-up on boot-up.  The size of the 
buffer is also displayed but can only be altered through changes 
in the configuration file.

                             DIALING
                             -------

Buttons are also present for a dial mode and VT-52 terminal mode.  
A click on DIAL brings up the dial dialog box.  At the top of 
the box are displayed the strings to be used by the modem.  These 
may be changed to suit your own modem.  The programmers were kind 
enough to allow for two non-connect strings.  This is important 
because many of the newer modems support more than one non-
connect string.  For example my modem uses both "NO CARRIER" and 
"BUSY" when it can't connect.  A total of 60 numbers can held 
within the dialer and other files can be loaded as required.  The 
format used is the same as the ".DIR" files used by the FLASH! 
terminal program.  Regrettably FLASH-style ".DO" files are not 
supported.

A click on the "DIAL" box, a short wait, and a "ding" from 
the bell confirms the connection.  At this point the user must 
toggle into the terminal mode.  A nice touch would have been to 
have the software dump you directly into the terminal mode on 
connect, but that's what upgrades are all about.  More on upgrades 
later.

                          VT-52 EMULATOR
                          --------------

The VT-52 emulator is pretty much a "plain vanilla" terminal which 
offers little more than the standard VT-52 codes.  Realistically, 
users of SHADOW aren't using it for the emulation, but rather for 
the transfer features.  The emulator is functional enough to get 
you to where you want to go and to start the transfer.

                           THE TRANSFER
                           ------------

The transfer is begun exactly as you would commence any other 
transfer.  Once the other end has initiated the transfer you would 
click on either send or receive, and supply the file name for your 
disk.  You then click on "BEGIN" and way we go.  At this point you 
may return to most GEM programs while the transfer takes place in 
the background.  There are toggles that allow display of a counter 
in the upper right corner of the screen to keep you posted on the 
progress of the transfer, and a bell toggle alerts you to the 
completion of the transfer.  Following the transfer the user must 
save the contents of the buffer to disk.  In the case of Y-MODEM 
Batch transfers the filenames are supplied and the you merely 
click on the "OKAY" box for each file.

When uploading, it's advisable to first load your file into the 
transfer buffer before initiating the transfer.  This is due to 
the length of time required for the load.  If the file is of any 
great length the transfer could be aborted due to time-outs from 
the other end.  The programmers have allowed for this by providing 
a "WAIT" button in the upload dialog box.  Clicking on "WAIT" 
allows the user to return to terminal mode and set up for the 
transfer.  When all is ready, the user simply returns to the 
upload and clicks on "SEND".  The long load time can be overcome 
through the use of a RAM Disk however.

Supplied along with the SHADOW software is a special reset-proof 
RAM Disk.  The documentation strongly recommends the use of this, 
and only this, special RAM Disk with SHADOW.  Memory conflicts are 
the primary reason for the insistence on this configuration.  The 
use of the RAM disk greatly speeds things up when large files are 
involved.  However, the amount of free RAM should be taken into 
consideration when deciding to employ the RAM Disk.

                          USE WITH FLASH
                          --------------

SHADOW is configured to work intimately with FLASH! Version 1.60, 
which has provisions for SHADOW built in.  Menu selections on the 
drop-downs allow easy access to SHADOW's features from within 
FLASH!.  The setting of parameters in FLASH! effects a change 
within SHADOW as well - such as selecting a new transfer protocol.  
The use of background transfers in FLASH is useful when you'd like 
to peruse a long list of new files but not waste expensive online 
time to do so.  Simply grab the first file you'd like, and as it 
downloads, look over the list.  Once the download has started you 
may exit to the desktop, reset the computer, and even change 
resolutions without adversely affecting the transfer in progress.  
You may even come back up with a program that doesn't have the 
SHADOW accessory, use it and following the termination of the 
transfer do a reset, load the accessory and then dump the contents 
of the buffer.  Once I even reset from FLASH and thought I had 
lost a rather long file.  Not a problem.  I simply loaded the 
accessory version and retrieved my file - intact.  The interface 
between FLASH! and SHADOW is seamless and well designed.  Both work 
well together even though the use of SHADOW as an accessory is a 
bigger advantage than using SHADOW from within FLASH!.  
Nonetheless, SHADOW is now a permanent addition to my FLASH! boot 
disk.

                         PLUSES & MINUSES
                         ----------------

The nitty-gritty you say?  Okay....  While SHADOW is a valuable 
tool, it can tend to be a memory hog.  Add a large buffer as you 
would for Y-MODEM Batch transfers, and add a large RAM Disk and a 
sizeable application to top it off and there isn't much room left.  
This is particularly true if you're running with 512K.

As already noted the terminal is bare-bones.  A few "bells & 
whistles" wouldn't hurt.  It would be very nice to be able to do 
an auto-logon using ".DO" files 'a la FLASH!.

One of the "trademarks" of Double Click Software is a lack of EXIT 
buttons in their dialog boxes.  This is especially noticeable when 
one considers the number of dialog boxes used in their programs.  
Double Click's solution to this problem is the use of the right 
mouse button.  In order to exit any dialog simply click right.  A 
right click will back up one level of prompts.  While this is a 
little awkward at first, it soon becomes second nature and tends 
to be faster than the EXIT box method.  Score one for Double 
Click.  Also, I found that SHADOW worked well in combination with 
the Universal Item Selector from Application & Design Software.  I 
look upon any program that doesn't allow use of the U.I.S. with a 
slightly jaundiced eye these days.

To date the only problem I've encountered is a failure on my part 
to insure that a large enough buffer was in place to receive the 
incoming file.  As a result a rather large file was lost along 
with some $$ for download time on GEnie.  It's doubtful that the 
software will ever be able to catch a problem such as this, and 
the user should monitor the file being transfered for size.  The 
next best thing has been implemented, however.  When a Y-MODEM 
Batch download exceeds the buffer size, all files up to the last 
intact file are preserved and can be saved.

The folks at ANTIC Software have used their heads in marketing the 
SHADOW package.  Don't have FLASH! version 1.60 you say?  Included 
on the SHADOW disk is a utility that will upgrade version 1.51 or 
1.52 to 1.60 which supports SHADOW.  Additonally, there is $15.00 
worth of Compu$erve time included.  Add to this the reliable 
support ANTIC is known for, and you have a superb package at a 
very affordable price.

                         The Bottom Line
                         ---------------

I tend to be judicious in the use of accessories.  They take time 
to load and steal RAM.  SHADOW, however, has managed to weasel 
it's way onto more of my disks than any other accessory.  I have 
logged many hours with SHADOW in both accessory and FLASH! 
configurations without any problem.  For a first release SHADOW 
appears to be a solid piece of software.  I wouldn't recommend 
SHADOW as your only terminal program, nor would I recommend it to 
beginners.  However, I would highly recommend it to the person 
with some telecommunications experience that desires to maximize 
their computing time.

Paul Lee, Mike Vederman, and the folks at ANTIC Software should be 
commended for a job well done.  I'm certain minor revisions will 
further enhance this remarkable piece of software.  SHADOW is 
available through Antic Software or through most Atari retailers.

SHADOW
------
The Multitasking File Transfer Answer, (C)1988 Double 
Click Software, Marketed by The Catalog, 544 Second Street, San 
Francisco, CA  94107,  (800) 234-7001.  $29.95.

Universal Item Selector
-----------------------
(Now Universal II), Application & Design 
Software, 226 N.W. 'F' Street, Grants Pass, OR  97526,  (503) 476-
0071.  $19.95.




--------------------------------------------------------------------------




                      GENIE CONFERENCE  ~  SEPT. 07, 1988
                      ===================================

                                      with

                          NEIL HARRIS and ATARI CORP.
                          ===========================

Attendees:
----------
1 Hadley,MA          GRIBNIF          2 Staten Island, NY   T.MCCOMB
3 Bartlesville,OK    J.VOGH           4 San Jose, CA        [Mark @ Atari]
5 Parma, OH          A.H.DAVIS        6 Jacksonville, FL    REX.READE
7 Arlington hgh, IL  JEFFWILLIAMS     8 Ravenna, OH         R.GRIDLEY
9 Lake Placid, FL    D.D.MARTIN      10 Browns Mills, NJ    MYSTICIAN
11 Salt Lake, UT     SANDY.W         12 Fremont, CA         [John @ Atari]

               13 Indianapolis,IN   [Holly] HS {Moderator}

14 Bolton, CT        ED-SECKLER      15 Sparks, NV          K.E.JOHNSON
16 Columbus, OH      APOSTLE         17 Newhartford, NY     M.ROSSI5
18 Berkeley, CA      M.WOLFMAN       19 Mountain View, CA   [Fred]
20 Clifton Park, NY  W.CROWLEY       21 Stockton, CA        T.WEINTZ
22 Mississauga, ON   DAREKM          23 Columbus, OH        P.PELFREY
24 Freeport, NY      JOHN-CARTER     25 Atari, CA           Neil @ Atari
26 Lauderhill, FL    N.RECHTMAN1     27 Portland, OR        M.CROMMIE
28 Orlando, FL       R.LAING         29 Kent, WA            DL.SHOWALTER 
30 Baltimore, MD     B.O.B.          31 Carrollton, TX      K.STRATTON
32 San Antonio, TX   T.CILLO         33 S.Barbara, CA       D.FAIRWEATH1
34 Erehwon, CA       SYNERGIST       35 Broderick, CA       DR.FATE
36 Paterson, NJ      V.AVERELLO      37 Baton Rouge, LA     J.CASCIO
38 Rockville, MD     JKUEHN          39 Portland, OR        R.HALL16
40 Jupiter, FL       CARINA          41 Englewood, CO       DAVESMALL
                      42 Morris Plains, NJ  D.BURRIS

                              <------------->

<[Holly] HS> Okay... welcome to our formal conference with some of our
favorite Atari folks. You all pretty much know how this runs, but for those
who don't.... if you have a question you'd like to ask, use the /RAI 
command to raise your hand and get into line.  I will ack your raise with
a private message and tell you who you'll follow so you know. I'll also 
try to give you some kind of warning when you're time is about to come up.
When you're through with your question, please let me know via some kind 
of ack like GA (Go Ahead) or something... it makes things a little easier.
Also, please remember that Neil and John are my guests tonight.  Please 
treat them accordingly.  *smile*  In two weeks, we have Charles Johnson
of G+Plus fame scheduled for a formal.  
I hope you'll make it... *plug*plug*

<[Neil] NHARRIS> And Mark.

<[John @ Atari] TOWNS> Please don't forget Mark

<[Holly] HS> Ooops!  I didn't know Mark was around!  Sorry...

<[Holly] HS> Let's start by having each of our guests introduce themselves
and let us know just what they do at our favorite computer company..*grin*

<[Holly] HS> Neil... you want to start?

<[Neil] NHARRIS> Sure. I've been with Atari Corp. for 4 years now, in a
variety of roles, including publishing Atari Explorer, heading up PR, user
group support, online support, advertising, product marketing, and sales 
for the east coast.  My current assignment is with the Federated stores,
specifically to bring them into the computer business.

<[John @ Atari] TOWNS> I have been with Atari Corp for almost a year
now. I work in the Technical Support Dept and handle a wide variety of
tasks. Everything from Online support to Shows to Technical Support on
the phones during the day. It makes it quite an interesting job and I get
the opportunity to meet alot of interesting people.

<[Mark @ Atari] MJANSEN> I've been with Atari for almost three years. I 
was the first technical support guy at New Atari, and then I moved into 
other things, like shows, West Coast Editing of Atari Explorer, Internal 
and Developer documentation, and various product development stuff, 
making sure New Things are Good Things.

<[Holly] HS> Thanks, Mark!  (New things are good things... I like that! 
*grin*)  Okay...if you have a question, please do a /RAI to get into line.

<[David F.] D.FAIRWEATH1> Neil, does Atari have a definite strategy for
increasing the ST's market share in the U.S. and will we see that strategy
implemented before the ST becomes obsolete? 

<[Neil] NHARRIS> Before implementing any strategy, the issue we're facing
is product availability.  We have been living from hand to mouth for some
time now.  The DRAM chip shortage hurts, because we  prefer to hold the 
line on pricing and that limits how many chips we can buy and how many 
machines to make. Right now, the lion lion's share of the computers are 
going to Europe, to keep the hottest ST market in the world supplied.  
Once we can get more machines built, the US will get our fair share.  
At that point  a strategy can be implemented.

<[David F.] D.FAIRWEATH1> O.K. but is there a defined strategy already in
waiting for that eventuality?

<[Neil] NHARRIS> Any strategy is time and market dependent.  If we had
machines to sell last year, we had a strategy ready.  If we have machines
this year, we have a strategy, but not the same one as last year, because
the product is more mature now, with more and better applications, and
because the market changes.  Next year's strategy is likely to be 
different again.

<[David F.] D.FAIRWEATH1> O.K. one last point... I think that when the 
time comes you should push the fact that with hardware and software 
emulation the ST is 3-way compatible with Mac and IBM.  that's all.

<[Neil] NHARRIS> I agree...  as a selling point it is important.  But when
people buy the hardware, I know they'll find enough fine ST-native 
software so the compatibility issues are not a factor.

<[David F.] D.FAIRWEATH1> I'm done thanks.

<[Rick] R.GRIDLEY> Mark, do you have any comments on the 3rd party
development of the 16mhz board?

<[Mark @ Atari] MJANSEN> Not really...I'll have more to say when I see 
one.

<[Rick] R.GRIDLEY> Ok, it sounds exciting.

<[Mark @ Atari] MJANSEN> Last I heard, it was still being worked on...

<[Rick] R.GRIDLEY> Neil, do you think that Atari owners are more concerned
with the status of the parent company than other computer owners?

<[Neil] NHARRIS> I think it is reasonable to be concerned with the company
which makes your computer, particularly in the case of a custom operating
system.  Apple users are concerned with Apple.  I doubt that most clone
owners care much about their company, they watch IBM.  Overall, it is
healthy, because the company steers the future development of the product
to a large extent.  Atari welcomes user inquiries and constructive 
criticisms, and we act upon them more frequently than is widely known. 
We love ya, honest we do.

<[Rick] R.GRIDLEY> Ok, (Grin) thanks and thanks to John with helping me 
with a problem about a year back. I am done thanks Holly

<D.D.MARTIN> huggs, Neil 1.  Any truth to the rumor that the laptop will 
be available by the end of the year? 2. IBM or MAC compatability is a _
major_ factor NEIL. The portability of office<-->home is a great selling 
feature.  And _we_ have a choice of the _best_ that is available in 
software to do the job at hand. 

<[Neil] NHARRIS> Any announcement of new hardware will have to wait for
Comdex, sorry.  Shipping times, too...

<D.D.MARTIN> I bow to comdex....grin

<[Neil] NHARRIS> I agree that it is an important selling factor, but we
won't let that overshadow the need for continuing development of TOS
programs.]  

<D.D.MARTIN> Atari users are prone to say.. I love _MY_ Atari, but I don't
know if I love Atari.... We all know we have the greatest personal 
computer available...you folks at Atari do to.... so who's job is it to 
tell the others? 

<[Neil] NHARRIS> Mainly ours, of course. But, from a BUSINESS perspective,
which is the only perspective that our boss takes, you have to look at the
return on any promoting we do.  Right now, we sell every computer we make.
We'd love to have enough computers to sell where we would have to 
advertise in order to move them all.  So, in the meantime, the grass 
roots, meaning the Atari community, has the main role.

<[Darek] DAREKM> My question is a rehash of one already asked, but, why
_not_ push the compatibility issue?  The Mac, PC, and Atari 800 <grin>
compatibility would interest a lot of people. Afterall, the 130XE looks 
very much like a 520, yet Atari rarely mixes ads of 8 bits and STs. 
However, you look in most Atari user group newsletters, and they mix the 
two computers all the time. Earlier tonight I was demoing my 8 bit drive 
to ST interface to a group of about 30 8 bit users (no ST users in the 
group) and about 1/4 of them indicated that they've thinking of getting 
an ST.  When I showed them 8 bit software booting off an Indus GT, they 
all indicated they are _more_ interested. Wouldn't it be a great way to 
upload a lot of 520s and single sided drives, by having some kind of 
upgrade policy for 8 bit users to upgrade to the ST. I know you're short 
of DRAMs, but with the RAM of a Mega 4 you can sell 8 520s. 

<[Neil] NHARRIS> The Mega uses 1 megabit DRAM chips.  The ST uses 256K-bit
chips. So, making a Mega does not impact production of ST's at all. There
has definitely been a solid trend toward 8-bit Atari users moving up to 
the ST.  But to reiterate, it is difficult to justify from a business 
sense, promoting a product when we don't have enough to satisfy the 
current demand.

<[Darek] DAREKM> The 8 bit users indicated that one of the reasons that
they'd like to upgrade is because the 8 bit software market is dead. I 
just see it as a great opportunity to get these potential ST owners before
they get tired of waiting and buy a non-Atari 16 bit product.

<[Neil] NHARRIS> I don't know how to sell our chairman on giving a special
deal to anyone, even our most favorite customers, at this time.

<[Darek] DAREKM> ok, thanks. (Keep pounding on him <grin>)

<[Neil] NHARRIS> He pounds back!

<[Norm] N.RECHTMAN1> Are there any plans to make a laser printer with more
memory for 1040 users? and how about a desk jet copy? 

<[Neil] NHARRIS> I think a better answer is for 1040 users to get more 
RAM.  The reason for that is this:  if you have RAM in the laser printer,
it ONLY helps you when you are printing.  If you put it in the computer, 
then it is available for other jobs as well. 4 megabytes comes in mighty 
handy when you are spreadsheeting, or doing a Cyber animation. I am not 
aware of plans for an ink jet printer from Atari, but again, we are not 
here to announce products tonight. 

<[Norm] N.RECHTMAN1> that was just a suggestion. I would really like to 
see PC hardware add ons 

<D.D.MARTIN> Three cheers for Atari taking the bull by the horns and 
making plans to move production back to the US of A!!!   Neil, can you 
tell us how things are progressing with the proposed plant in Houston?

<[Neil] NHARRIS> Well, our negotiating team is still terrorizing the folks
in Texas.  We expect some news shortly, but at the moment, nothing new to
report at this time. 

<D.D.MARTIN> you are just _full_ of news tonight, hahahahahahah    done

<[Dan] GRIBNIF> I have two questions: First, what is the current status of
the CD ROM? 

<[Neil] NHARRIS> Mark?  Please jump in here. You're a bit closer to this
than I am.

<[Dan] GRIBNIF> oooh! buck passing...<grin>

<[Mark @ Atari] MJANSEN> Most recent I heard is that we're trying to get
some good applications together... Makes more sense than saying "Here's a
CD-ROM player. Go to Tower Records and buy some CDs.  Have a good time." 
It would be nice if there was something to _do_ with it first. ...so we're
working on it.

<[Dan] GRIBNIF> Is that the only setback? Does it work with a Laser and HD
yet?

<[Mark @ Atari] MJANSEN> Yes.  And headphones.  :-)

<[Dan] GRIBNIF> <smile>

<[Neil] NHARRIS> There is a driver for the CD ROM that lets it be read by
TOS applications as if it were a really big drive.  You can open it
from the desktop and read files directly.  So now it is a fairly simple
matter of getting software which reads the databases on the  CD ROM disks
and does something with it. 

<[Mark @ Atari] MJANSEN> Doing a "Show Info..." is fun!

<[Dan] GRIBNIF> (I was reffering to the rumored problems with other DMA
devices)

<[Mark @ Atari]  I know several people with the setup you described.

<[Dan] GRIBNIF> ok, thanks. The other question is one that Neil probably 
saw in my letter to Info-Atari16... I was curious as to how normal users 
(not developers) will be notified of TOS 1.4...

<[Mark @ Atari] MJANSEN> Skywriting, blimps, dancing girls...(sorry, I
couldn't resist.) and if they will also be provided with an "official"
way of reporting bugs. 

<[John @ Atari] <grin>

<[Mark @ Atari] > Well, it's like this... People will find out
through magazines, etc. And dealers will know about it.  The plan is
to polish up a little program we've got here that is used for developers to
submit bug reports, and release that to the public too.

<[Neil] NHARRIS> Through the dealers, primarily.  And through all the
communications at our disposal.

<[Dan] GRIBNIF> "through magazines, etc??" Atari Explorer is still 
reviewing things that came out 8 months ago as NEW!

<[John @ Atari] TOWNS> I believe that the information will also be
published in the  User's Group newsletter as well (Right, Neil?)

<[Neil] NHARRIS> Like I said, through all the communications vehicles
at our disposal.  I tend to think the Atari community is very well wired
together. 

<[Dan] GRIBNIF> ok, now THAT's more like what I wanted to hear <smile>
yes, I tend to agree. Sorry about that comment a second ago sounding a 
bit huffy..

<D.A.BRUMLEVE> Apple saturated the school market here several years ago 
with a special offer on IIcs. Several teachers I know are dissatisfied 
with it and its software. But the school system will need a huge incentive
to invest more in computers. These teachers want to run ST programs. Any 
hope at all of an educational discount on basic color models?

<[Mark @ Atari] MJANSEN> Well, on a related note, we've been working with
DeAnza College, (largest community college in U.S.) integrating the ST 
into some of their classes. The first is their 680x0 assembly classes, 
which was an easy kill for us, since the ST is such a good platform for 
learning 68k assembly.  The plan is to move the STs into other courses as
well, and see how things go, how much interest we can drum up, etc.  So 
far reaction is VERY good, and the program hasn't even officially started
yet.  People are going into the lab, sitting down at STs, and being 
productive.  That makes them very happy. 

<[John @ Atari] TOWNS> I am also working on getting several 1040STs into a
Community college in Nevada for use as animation systems in a Art Program.
As well as the Boy's Club in Los Angeles for Music Related Study.

<D.A.BRUMLEVE> I don't think you guys understand...

<[Neil] NHARRIS> Dot, let me ask you a question.  Do teachers want to run
curriculum-specific software, or are they more interested in applications
packages?

<D.A.BRUMLEVE> The ST is very well adapted for little kids? They are
interested in applications for little kids. MY applications, no less. 7
teachers, and they say there will be more. And they need to get the
computers cheap!

<[Neil] NHARRIS> Do we have enough to present to them?  I am familiar
with your programs, and many from Unicorn and First Byte.  Is
that sufficient?

<D.A.BRUMLEVE> One single program I just finished sold them. But they 
need a good price before they can approach the school board.

<[Neil] NHARRIS> What kind of price on a 520 color system would they need?

<D.A.BRUMLEVE> I don't know, probably $500 would do it.

<[Neil] NHARRIS> $500 would be an incredible price. How much did they pay
for //C systems?

<D.A.BRUMLEVE> Apples were much less. They were practically "given" them,
I'm told.  See, when people are asked to recommend a computer for a kid,
they almost always say "get him the type they have at school" and the folks
go out and buy an Apple and Apple makes up for giving the computer to the
school.

<[Neil] NHARRIS> Dot, I think we should continue this conversation
offline or perhaps you should state your case to Jack and Sam Tramiel
in a letter. 

<D.A.BRUMLEVE> OK. 

<J.VOGH> Do you intend to introduce systems that are ready or almost ready
to ship from now on?

<[Neil] NHARRIS> I certainly hope so.

<[Vince] V.AVERELLO> Any Atari folks have anything to say about the 
lawsuit against Federated's old owners and their accountants ?

<[Neil] NHARRIS> I'm rooting for our side. <grin>

<[John @ Atari] TOWNS> Me too.

<[Neil] NHARRIS> Seriously though, the original deal had the proviso that
once Atari took control, we could thoroughly audit audit the assets and
compare them to what was stated, and that we would reconcile any
discrepancy.  I was not expecting a lawsuit to be necessary, but that's
sometimes the way things go in the world of business. 

<[Vince] V.AVERELLO> Ok... In reference to the laser printer question
before, does Atari recomend any specific memory upgrade for 1040's or will
Atari offer some type of upgrade of their own ?

<[Mark @ Atari] MJANSEN> Well, excuse me, I must go...Goodnight, all!

<[Neil] NHARRIS> We don't plan to offer any upgrades.  Please ask your
dealer or your user group, or ask online on the GEnie bulletin board.
I am sure people will be glad to share their experiences and advice with
you. 

<[Vince] V.AVERELLO> Also about the CD, what happened to the old CD 
software (Activenture's ?) .. ?

<[Neil] NHARRIS> It was written specifically for the Grolier's 
encyclopedia.  While I am not totally familiar with the situation, I hear
that the relationship betwen Knowledgeset (formerly Activenture) and 
Groliers, is no more.

<[Vince] V.AVERELLO> Thanks ...

<[Holly] HS> Thanks, Vince...  I have 4 more people in the queue... that's
going to be the end for this evening... should about take us close to the
end.  Thanks!

<W.V.FISHER> Neil - Will the driver work with other CD's and is it 
available now? 

<[Neil] NHARRIS> The driver works with any CD in the High Sierra format. 
If you are interested in becoming a CD ROM developer for Atari, please 
contact Mike Shmall here. 

<W.V.FISHER> I did, months ago.... 

<[John @ Atari] TOWNS> Please leave me Mail. I will make sure something 
gets to you.

<W.V.FISHER> Thanks !

<B.O.B.> Just wanted to let you all know that I'm listening to Tangerine
Dream's new CD, "Optical Race."   Fabulous. Emblazoned on the package is
the following... "This album has been produced on the ATARI ST using 
Steinberg / Jones Software."  WOW...

<[Neil] NHARRIS> You should see that on many upcoming Tangerine Dream
albums.

<[John @ Atari] TOWNS> Yes, nice isn't it?  We are currently sponsoring 
their US Tour.

<[Neil] NHARRIS> And probably from other artists.

<B.O.B.> zounds good.

<D.D.MARTIN> For those who have heard the story, bear with me. My boy 
friend had an XT CLONE, 20 meg hard drive, internal modem, color card, 
3_and_5 inch floppy, mouse.. the whole nine yards. He traded the all in 
for a 1040 ST.  WHY YOU ASK?  He wanted to be PRODUCTIVE!  THAT IS WHAT 
MAKES ATARI THE GREAT MACHINE IT IS.  No MS-DOS, ease of use and getting 
things done...His "switch over" came as a result of being EXPOSED to what
an Atari can do and how easily it does it!Neil.. need a salesman?...grin.
Atari is still a family machine....a great selling point. EASY, AFFORDABLE
and PRODUCTIVE! A computer doesn't have to be complicated to be good.

<[Neil] NHARRIS> <clapping>

<D.D.MARTIN> How ya gonna EXPOSE yourself, NEIL??

<[John @ Atari] TOWNS> I am glad you and your Boyfriend enjoy your Atari
Computer

<D.D.MARTIN> his and hers....

<[Norm] N.RECHTMAN1> OK, one question and 1 statement.  How much longer is
the price of the MEGA packages gonna stay at special?  

<[Neil] NHARRIS> There has been no word on duration.  I would not be
surprised if the specials lasted through the end of 1988, but the official
answer would have to be that it could end at any time. The promotion has
been fairly successful, so I don't see why we would not want it to 
continue.

<[Norm] N.RECHTMAN1> ok, I would like to see some special application
software like on the MAC One is being used by Paramedics called caller Aid
and the other is used nationally for HAZ MAT teams called CAMEO Our
department just spent 4000 on a MAC SE, what a waste of money, they could
of had 4 ST's to put in other trucks 

<[Holly] HS> Well, that clears the queue for the evening... any final
remarks Neil and John?

<[Neil] NHARRIS> Yup. People, next time we do one of these conferences,
please don't be afraid to ask hard questions.  I noticed several folks who
have been very vocal, lurking in the background.  A public event like this
seems to me like the idea forum to get some realtime give and take going,
to clear the air.  I don't expect people like Rex Reade to get shy on us!
Aside from that, thanks all for your continued support, and for coming out
tonight.  See you online.

<[John @ Atari] TOWNS> I just would like to say that if you have questions
or problems regarding Atari products, please ask! That's what we are here
for I am constantly reading the BB as well as my mail for these  things 
and I know the other Atari people do the same. So, if you have a problem 
or need help, please speak up! We would love to  make you a happy 
customer! And Thanks for coming...

<[Holly] HS> Well, gosh, since you guys liked this so much... how
about we do it again about the first week in December?  *grin*  Make it a
quarterly thing... 

<[Neil] NHARRIS> I'm busy that night.  :-)

<[Holly] HS> Thank you all... and all our questioners, too... 

<[John @ Atari] TOWNS> I will again be attending the regular RTC
starting next week...

<[Holly] HS> Back into feeding frenzy mode!



                    :HOW TO GET YOUR OWN GENIE ACCOUNT:
                     ---------------------------------

       To sign up for GEnie service: Call: (with modem) 800-638-8369.

               Upon connection type HHH (RETURN after that).  
                          Wait for the U#= prompt.  
                    Type XJM11877,GEnie and hit RETURN.  
             The system will prompt you for your information.




--------------------------------------------------------------------------



                                  DO IT to IT!
                                  ============

by Rex Reade

The subject this week is the fine art of growing MUSHROOMS....

First, let me say thank you to Neil Harris of Atari Corp. for giving us 
some thought in a recent Online Conference.  How nice it feels to know 
you are on someone's mind.   (Did I say that?) ;-)

More and more it becomes easier to grimace when you hear "they" are
holding an information session (CO) for the benefit of the Atari Userbase.
Is it really for the userbase' benefit or the continuation of what I call,
affectionately, the fine art of non-information.

In all fairness to those who were in attendance, it sounded smooth and
reassuring, but if you go back over what was said you will find that....
nothing of any real consequence was said....EXCEPT a bit of negative 
fodder by Atari (Neil) about why they couldn't deliver.  Even to the point
of saying that the 3rd party emulators have little or no effect on the 
sales of Atari ST computers.  To that I say, WRONG!!! Those emulators: 
Spectre 128, PC Ditto and others tend to MAGNIFY the power of the ST line
to the umpteenth degree and usually are the trump card in closing a good
sale.  Especially if bundled.

All is not lost though folks, again, We are waiting patiently for the
Grand Revelations destined to be heard at COMDEX LAS VEGAS.  

Those of you who attended the CO noticed the point was made that the CO 
was not for New Product Info, I saw no old product info either, did You?
What was the CO for ....I suggest an exercise in futility and that is the
reason, in particular, that we remained silent....we refused to be part of
this "show up but say nothing" CO.  It has to be the most lackluster CO
I have attended....  Again, this in no way reflects on the attendees or 
the folks running the CO....just Atari and it's totally predictable 
attitude toward the users of the U.S.A.  They wouldn't last five days in 
Europe if they acted the same way there.

They said in the CO, the responsibility of promoting  Atari belongs to
the "Grassroots"...well being part of the grassroots I am tired of doing
your job and getting treated like the proverbial mushroom patch!  The 
grassroots are not going to go for it for another year and you can bet on
that! 

Atari offered nothing but excuses to us at this CO, it is sad, I hope this
is not the case at the Las Vegas Comdex.  Wouldn't it be nice if a lion's
share of those machines destined for Europe were rerouted to the USA in
time for the holidays?  or...must Atari be reminded that it ALL started
here with U.S. Dollars!  Also, No mention being made of the TOS upgrade 
so strongly touted at Spring Comdex was another point , if it isn't quite 
ready SAY SO! Just in case you didnt know, this is September, you know, 
after Labor Day, when the leaves are turning colors and still no NEWS of 
the pending release.  (Sept. 22 is a week from this WED.)

I respectfully submit that the time has arrived for all the Atari users
and future users to watch closely, Atari has the center stage, is Atari
once again going to say THUMBS DOWN to Userbase in the United States and 
just trickle sell the grassroots here while romancing and courting Europe 
like a fat bottomed painted lady?  Let's wait and see......  I HOPE NOT!

                                       Rex......


ps: The Art of growing mushrooms is to "Keep them in the Dark and cover
them with sheepdip (organic fertilizer) regularly".




--------------------------------------------------------------------------




ST REPORT CONFIDENTIAL
======================


Billerica, MA   A Series Programmable Serial Interface is now available,
-------------   it will allow multi-line usage with the ST. ie., a BBS
                with more than one caller at a time, up to 8 lines.

Framingham, MA  Matt Singer, a dynamic and dedicated developer in the
--------------  Atari Community for years is now developing a MULTI-CALLER
                FOREM BBS.  He is also waiting for what must seem an
                eternity for HIS MEGA to be delivered from Atari.

Littleton, CO   Dave Small, Owner of GBS Inc., announced the success of
-------------   the SPECTRE 128.  It will be available at the Glendale
                Atari Fair and will start shipping in 2 weeks.

Sunnyvale, CA   Sig Hartmann, Exec. V.P. Atari Corp. Rescued Seaman
-------------   Neil Bradley, stationed on a destroyer in the Middle
                East, who had severe problems with the mouse for his ST. 
                Thanks to Sig, another is on the way!  Way to Go Atari!!!

Sunnyvale, CA   Seems there will be a version of the laptop with a hardisk
-------------   built in.  LOOK for a 286/386 [PC-5/6] clone from our 
                favorite Co.  The STGS will debut in the first quarter
                of 1989.        (The first 68000 Game Machine)

Hanover, GDR    Atari is strongly considering opening a plant here to
------------    manufacture semiconductors, 1 & 4mb memory chips.
                GDR = GERMAN DEMOCRATIC REPUBLIC.

Houston, TX     Still NO INK on the paper...Is Atari serious?? Or, Is this
-----------     one for Fantasy Land??? 

Sunnyvale, CA   There is still a good chance that the NEW TOS will be able
-------------   to read more 16mb per partition and also read more than 12
                partitions.  Soft coded vs Hard coded?

NYC, NY         ST Report and other confidential sources agree that:
-------         ATARI will SLOWLY accelerate it's marketing push in the
                USA to reach a goal of 35 to 55% of it's global computer
                sales by 1990-91.



--------------------------------------------------------------------------


OF SPECIAL NOTE:
================


                      ***  THE NEW MACINTOSH EMULATOR  ***
                                 -= SPECTRE 128 =-

    is NOW available, if you did not receive a newsletter about this 
    marvelous device, then call Gadgets by Small Inc. at 303-791-6098. 

                                ORDER YOURS NOW!


This Item provided to show our support for David and Sandy Small and our
total disgust with the behavior of DP.


--------------------------------------------------------------------------



                           ANTIC PUBLISHING INC.
                              COPYRIGHT 1988
                          REPRINTED BY PERMISSION.



    Professional GEM  by Tim Oren
    Column #3 - The Dialog Handler


    A MEANINGFUL DIALOG

       This  issue  of ST PRO GEM begins an exploration of ST GEM's dialog
    handler.  I will discuss basic system calls for presenting the dialog,
    and  then continue with techniques for initializing and reading on/off
    button  and  "radio"  button  objects.   We  will also take some short
    side-trips  into the operation of the GEM Resource Construction Set to
    assist you in building these dialogs.

       There are a number of short C routines which accompany this column.
    These  are  stored  as  file  GEMCL3.XMO in DL 5 on SIG*ATARI.  Before
    reading  this  column,  you  should  visit  SIG*ATARI (go pcs-132) and
    download this file.


    DEFINING TERMS

       A  dialog  box is an "interactive form" in which the user may enter
    text  and  indicate selections by pointing with the mouse.  Dialogs in
    GEM  are  "modal",  that  is,  when a dialog is activated other screen
    functions  such  as  menus and window controls are suspended until the
    dialog is completed.

       In  most  cases,  the visual structure of a GEM dialog is specified
    within   your   application's   resource   file.    The  GEM  Resource
    Construction Set (RCS) is used to build a picture of the dialog.

       When the RCS writes out a resource, it converts that picture into a
    tree  of GEM drawing objects and stores this data structure within the
    resource.   Before  your  application  can display the dialog, it must
    load this resource file and find the address of the tree which defines
    the dialog.

       To  load  a  resource, the AES checks its size and allocates memory
    for  the  load.   It  then  reads  in the resource, adjusting internal
    pointers  to  reflect  the  load  address.   Finally, the object sizes
    stored  in  the resource are converted from characters to pixels using
    the system font size.

       (A  note for those with Macintosh experience:  Although Mac and GEM
    resources share a name, there are fundamental differences which can be
    misleading.  A Mac resource is a fork within a file; a GEM resource is
    a  TOS  file  by  itself.   Mac  resources  may be paged in and out of
    memory;  GEM  resources  are monolithic.  GEM resources are internally
    tree  structured;  Mac  resources  are  not.   Finally,  Mac resources
    include  font information, while ST GEM does this with font loading at
    the VDI level.)

       The resource load is done with the GEM AES call:

        ok = rsrc_load(ADDR("MYAPP.RSC"));

       "MYAPP"  should  be  replaced  with  the  name  of  your  program.
    Resources   conventionally   have  the  same  primary  name  as  their
    application,  with  the  RSC  extent name instead of PRG.  The ok flag
    returned  by rsrc_load will be FALSE is anything went wrong during the
    load.

       The most common causes of failure are the resource not being in the
    application's  subdirectory,  or  lack of sufficient memory for GEM to
    allocate  space for the resource.  If this happens, you must terminate
    the program immediately.

       Once  you  have  loaded  the  resource,  you  find the address of a
    dialog's object tree with:

        rsrc_gaddr(R_TREE,MYDIALOG,&tree);

    Tree  is  a 32-bit variable which will receive the address of the root
    node of the tree.

       The  mnemonic  MYDIALOG  should  be replaced with the name you gave
    your  dialog  when  defining  it in the RCS.  At the same time that it
    writes  the resource, RCS generates a corresponding .H file containing
    tree  and  object  names.  In order to use these mnemonics within your
    program,  you  must  include  the name file in your compile:  #include
    "MYAPP.H"


    BUG ALERT!

       When  using  the  DRI/Alcyon  C  compiler,  .H files must be in the
    compiler's  home  directory  or  they  will  not  be  found.   This is
    especially  annoying  using a two floppy drive ST development system.
    The  only way around this is to explicitly reference an alternate disk
    in the #include, for instance:  "B:MYAPP.H"

       Now  that  the  address  of the dialog tree has been found, you are
    ready to display it.  The standard (and minimal) sequence for doing so
    is  given  in  routine  hndl_dial() in the download.  We will now walk
    through each step in this procedure.

       The  form_center call establishes the location of the dialog on the
    screen.   Dialog  trees  generated by the RCS have an undefined origin
    (upper-left corner).

       Form_center  computes  the  upper-left location necessary to center
    the dialog on the screen, and inserts it into the OB_X and OB_Y fields
    of the ROOT object of the tree.  It also computes the screen rectangle
    which   the  dialog  will  occupy  on  screen  and  writes  its  pixel
    coordinates into variables xdial, ydial, wdial, and hdial.

       There  is  one peculiarity of form_center which occasionally causes
    trouble.   Normally  the rectangle returned in xdial, etc., is exactly
    the same size as the basic dialog box.

       However,  when  the OUTLINED enhancement has been specified for the
    box,  form_center adds a three pixel margin to the rectangle returned.
    This  causes the screen area under the outline to be correctly redrawn
    later  (see below).  Note that OUTLINED is part of the standard dialog
    box  in  the  RCS.   Other enhancements, such as SHADOWED or "outside"
    borders  are  NOT handled in this fashion, and you must compensate for
    them in your code.

       The  next  part  of  the  sequence  is a form_dial call with a zero
    parameter.   This  reserves  the screen for the dialog action about to
    occur.   Note  that  the  C  binding  given  for  form_dial in the DRI
    documents is in error: there are nine parameters, not five.  The first
    set  of  xywh  arguments is actually used with form_dial calls 1 and 2
    only, but place holders must be supplied in all cases.

       The succeeding form_dial call (parameter one) animates a "zoom box"
    on  the  screen  which moves and grows from the first screen rectangle
    given to the second rectangle, where the dialog will be displayed.

       The  use of this call is entirely optional.  In choosing whether to
    use it or not, you should consider whether the origin of the "zoom" is
    relevant  to the operation.  For instance, a zoom from the menu bar is
    relatively meaningless, while a zoom from an object about to be edited
    in  the  dialog  provides visual feedback to the user, showing whether
    the correct object was chosen.

       If the origin is not relevant, then the zoom is just a time-waster.
    If  you  decide  to  include  these  effects, consider a "preferences"
    option  in your app which will allow the experienced and jaded user to
    turn them off in the interests of speed.

       The  objc_draw  call  actually  displays the dialog on the screen.
    Note  that  the address of the tree, the beginning drawing object, and
    the  drawing  depth  are passed as arguments, as well as the rectangle
    allotted for the dialog.

       In  general,  dialogs  (and  parts  of  dialogs)  are  ALWAYS drawn
    beginning  at  the  ROOT  (object zero).  When you want to draw only a
    portion  of  the  dialog,  adjust  the clipping rectangle, but not the
    object  number.   This  ensures  that  the background of the dialog is
    always drawn correctly.

       The  objc_xywh()  utility  in  the download can be used to find the
    clipping rectangle for any object within a dialog, though you may have
    to  allow  an  extra  margin  is  you  have used shadows, outlines, or
    outside borders with the object.

       Calling  form_do  transfers  control to the AES, which animates the
    dialog for user interaction.  The address of the dialog tree is passed
    as  a  parameter.   The  second paramter is the number of the editable
    object at which the text cursor will first be positioned.  If you have
    no text fields, pass a zero.  Note that again the DRI documents are in
    error:  passing  a  -1  default may crash the system.  Also be careful
    that  the default which you specify is actually a text field; no error
    checking is performed.

       The  form_do  call  returns  the  number of the object on which the
    clicked to terminate the dialog.  Usually this is a button type object
    with  the  EXIT  and  SELECTABLE  attributes set.  Setting the DEFAULT
    attribute  as  well  will  cause  an exit on that object is a carriage
    return is struck while in the dialog.

       If  the  top  bit  of the return is set, it indicates that the exit
    object   had   the   TOUCHEXIT  attribute  and  was  selected  with  a
    double-click.  Since very few dialogs use this combination, the sample
    code simply masks off the top bit.

       The next form_dial call reverses the "zoom box", moving it from the
    dialog's  location back to the given x,y,w,h.  The same cautions apply
    here as above.

       The final form_dial call tells GEM that the dialog is complete, and
    that  the screen area occupied by the dialog is now considered "dirty"
    and  needs  to  be  redrawn.   Using the methods described in our last
    column, GEM then sends redraws to all windows which were overlaid, and
    does any necessary redrawing of the menu or desktop itself.

       There  is one notable "feature" of form_dial(3):  It always redraws
    an  area which is two pixels wider and higher than your request!  This
    was  probably included to make sure that drop-shadows were cleaned up,
    and is usually innocuous.


    A HANDY TRICK

       Use  of  the  form_dial(3) call is not limited to dialogs.  You can
    use  it  to  force  the  system to redraw any part of the screen.  The
    advantage of this method is that the redraw area need not lie entirely
    within a window, as was necessary with the send_redraw method detailed
    in  the  last  column.  A disadvantage is that this method is somewhat
    slower, since the AES has to decide who gets the redraws.


    CLEAN UP

       As  a  last step, you need to clear the SELECTED flag in the object
    which  was  clicked.   If you do not do this, the object will be drawn
    inverted  the next time you call the dialog.  You could clear the flag
    with  the GEM objc_change call, but it is inefficient since you do not
    need to redraw the object.

       Instead,  use  the desel_obj() code in the download, which modifies
    the  object's OB_STATE field directly.  Assuming that ret_obj contains
    the exit object returned by hndl_dial, the call:

        desel_obj(tree, ret_obj);

    will do the trick.


    RECAP

       The  basic  dialog  handling method I have described contains three
    steps:  initialization  (rsrc_gaddr), dialog presentation (hndl_dial),
    and cleanup (desel_obj).

       As  we  build more advanced dialogs, these same basic steps will be
    performed,  but  they will grow more complex.  The initialization will
    include  setting  up  proper  object  text and states, and the cleanup
    phase  will  also  interrogate the final states of objects to find out
    what the user did.


    BUTTON, BUTTON

       The  simple  dialogs  described  above contain only exit buttons as
    active  objects.   As  such, they are little more than glorified alert
    boxes.

       We  will  now  increase  the  complexity  a  little  by considering
    non-exit  buttons.   These  are  constructed by setting the SELECTABLE
    attribute on a button object.

       At  run-time, such an object will toggle its state between selected
    (highlighted)  and  non-selected whenever the user clicks on it.  (You
    can  set  the  SELECTABLE  attribute of other types of objects and use
    them instead of actual buttons, but be sure that the user will be able
    to figure out what you intend!)

       Having  non-exit  buttons  forces  us  to  consider  the problem of
    initializing  them  before the dialog, and interrogating and resetting
    them afterward.

       Since  a  button  is a toggle, it is usually associated with a flag
    variable  in  the  program.  As part of the initialization, you should
    test the flag variable, and if true call:

        sel_obj(tree, BTNOBJ);

    which  will  cause the button to appear highlighted when the dialog is
    first  drawn.   Sel_obj() is in the download.  BTNOBJ is replaced with
    the  name  you gave your button when you defined it in the RCS.  Since
    the  button  starts  out  deselected, you don't have to do anything if
    your flag variable is false.

       After  the  dialog  has  completed,  you need to check the object's
    state.   The  selectp() utility does so by masking the OB_STATE field.
    You  can  simply assign the result of this test to your flag variable,
    but  be  sure that the dialog was exited with an OK button, not with a
    CANCEL!  Again,  remember  to  clean  up the button with desel_obj().
    (It's  often easiest to deselect all buttons just before you leave the
    dialog routine, regardless of the final dialog state.)


    WHO'S GOT THE BUTTON?

       Another common use of buttons in a dialog is to select one of a set
    of  possible  options.  In GEM, such objects are called radio buttons.
    This  term recalls automobile radio tuners where pushing in one button
    pops  out  any others.  In like fashion, selecting any one of a set of
    radio buttons automatically deselects all of the others.

       To use the radio button feature, you must do some careful work with
    the Resource Construction Set.

       First,  each  member  of a set of radio buttons must be children of
    the  same  parent  object  within  the  object  tree.   To create this
    structure,  put  a  hollow  box type object in the dialog, make it big
    enough  to  hold all of the buttons, and then put the buttons into the
    box one at a time.

       By  nesting the buttons within the box object, you force them to be
    its  children.   Each of the buttons must have both the SELECTABLE and
    RADIO  BUTTON  attributes  set.   When  you are done, you may make the
    containing  box  invisible  by  setting its border to zero, but do not
    FLATTEN it!

       Since  each  radio  button  represents a different option, you must
    usually  assign  a name to each object.  When initializing the dialog,
    you  must  check  which  option  is  currently  set,  and  turn on the
    corresponding button only.  A chain of if-then-else structures assures
    that only one button will be selected.

       At  the  conclusion  of the dialog, you must check each button with
    selectp()  and make the appropriate adjustments to internal variables.
    Again,  an if-then-else chain is appropriate since only one button may
    be  selected.   Either deselect the chosen button within this chain or
    do them all at the end.

       There is one common use of radio buttons in which you may short-cut
    this procedure.  If the buttons each represent one possible value of a
    numeric variable, for instance, a set of selector buttons representing
    colors  from  zero  to  seven, then you can compute the initial object
    directly.

       In  order  for  this  technique  to  work,  you  must use a special
    capability  of  the  RCS.   Insert  the object corresponding to a zero
    value  at  the  top  (or  left) of your array of buttons, then put the
    "one" button below (or right) of it, and so on.

       When  the  buttons  are  complete,  the  SORT  operation is used to
    guarantee  that  the top/left object is in fact the first child of the
    parent  box with the others following in order.  Due to the details of
    object  tree structure (to be discussed in the next column), this will
    guarantee that these objects are contiguous in the resource.

       If  you  assign  a name (say BUTTON1) to the first button, then you
    can initialize the correct button with the call:

        sel_obj(tree, BUTTON1 + field);

    where field is the variable of interest.

       When  the  dialog  is  complete,  you can scan the radio buttons to
    compute  the  new  value  for  the  underlying variable.  The encode()
    procedure  in  the  download  will  do  this.   As always, remember to
    deselect the buttons at the end.

       You  can use offsets or multipliers if your variable's values don't
    start  with zero or increment by one.  If the values are irregular you
    may be able to use a lookup table, at the cost of additional code.


    COMING UP NEXT

       In the next column, I will discuss the internal structure of object
    trees.   Then  we'll use that knowledge to build a piece of code which
    will "walk" an entire tree and apply a function to each object.  We'll
    apply  this code to do all of the button deselects with a single call!
    I'll  also look at handling editable text fields and discuss some ways
    to alter a dialog's appearance at run-time.


    DISPELL GREMLINS

       An  editing error caused an omission in the first installment of ST
    PRO  GEM.   The window components RTARROW and DNARROW should have been
    listed along with HSLIDE as the horizontal equivalents of the vertical
    slider components which were discussed.




>>>>>>>>>>>>>>>>>>>>>>> Basic Dialog Handler <<<<<<<<<<<<<<<<<<<<<<<

     WORD
hndl_dial(tree, def, x, y, w, h)
     LONG     tree;
     WORD     def;
     WORD     x, y, w, h;
     {
     WORD     xdial, ydial, wdial, hdial, exitobj;

     form_center(tree, &xdial, &ydial, &wdial, &hdial);
     form_dial(0, x, y, w, h, xdial, ydial, wdial, hdial);
     form_dial(1, x, y, w, h, xdial, ydial, wdial, hdial);
     objc_draw(tree, ROOT, MAX_DEPTH, xdial, ydial, wdial, hdial);
     exitobj = form_do(tree, def) & 0x7FFF;
     form_dial(2, x, y, w, h, xdial, ydial, wdial, hdial);
     form_dial(3, x, y, w, h, xdial, ydial, wdial, hdial);
     return (exitobj);
     }


>>>>>>>>>>>>>>>>>>>>>>> Object rectangle utility <<<<<<<<<<<<<<<<<<<<<<<<<

     VOID
objc_xywh(tree, obj, p)          /* get x,y,w,h for specified object     */
     LONG     tree;
     WORD     obj;
     GRECT     *p;
     {
     objc_offset(tree, obj, &p->g_x, &p->g_y);
     p->g_w = LWGET(OB_WIDTH(obj));
     p->g_h = LWGET(OB_HEIGHT(obj));
     }


>>>>>>>>>>>>>>>>>>>>>> Sample radio buttons after dialog <<<<<<<<<<<<<<<<<<<<

     WORD
encode(tree, ob1st, num)
     LONG     tree;
     WORD     ob1st, num;
     {
     for (; num--; )
          if (selectp(ob1st+num))
               return(num);
     return (-1);
     }


>>>>>>>>>>>>>>>>>>>>>>> Object flag utilities <<<<<<<<<<<<<<<<<<<<<<<<<<<

     VOID
undo_obj(tree, which, bit)     /* clear specified bit in object state     */
     LONG     tree;
     WORD     which, bit;
     {
     WORD     state;

     state = LWGET(OB_STATE(which));
     LWSET(OB_STATE(which), state & ~bit);
     }

     VOID
desel_obj(tree, which)          /* turn off selected bit of spcfd object*/
     LONG     tree;
     WORD     which;
     {
     undo_obj(tree, which, SELECTED);
     }

     VOID
do_obj(tree, which, bit)     /* set specified bit in object state     */
     LONG     tree;
     WORD     which, bit;
     {
     WORD     state;

     state = LWGET(OB_STATE(which));
     LWSET(OB_STATE(which), state | bit);
     }

     VOID
sel_obj(tree, which)          /* turn on selected bit of spcfd object     */
     LONG     tree;
     WORD     which;
     {
     do_obj(tree, which, SELECTED);
     }

     BOOLEAN
statep(tree, which, bit)
     LONG     tree;
     WORD     which;
     WORD     bit;
     {
     return ( (LWGET(OB_STATE(which)) & bit) != 0);
     }

     BOOLEAN
selectp(tree, which)
     LONG     tree;
     WORD     which;
     {
     return statep(tree, which, SELECTED);
     }



-------------------------------------------------------------------------



                               TLC for a MOUSE
                               ===============


     If you're using a computer equipped with a mouse, take time in taking
care of your little opti-electro-mechanical friend.  As the hyphens in
the last sentence suggest, the rodent's got a lot going on inside, and
some simple cleaning can keep it working for you.

     First off, remember that more rodents die from mangled cords than
anything else.  So... keep the excess out of the way (coiled under the
computer/keyboard).

     Really, only three items need attention: The ball, The rollers, 
and Dust Removal.  Now, that doesn't sound too hard, does it?

Now, The Procedure:
-------------------

First,  Remove the ball.  

Second, Open the mouse up.  Look around inside.  There will be three or 
        four rollers that the ball turns on.  Check that these have no 
        hair or other fibers wound around them, swab them with a Q-Tip 
        dipped in rubbing alcohol.  Then, blow dust out of the mouse's 
        interior, particularly around the area where the LEDs are.  (If 
        that isn't apparent, just get as much dust out of the inside as 
        you can).  Put the mouse case back together.  

Third,  Wipe the ball off with a tissue moistened with alcohol, and put 
        it back into the case.  Don't forget to vacuum your mouse pad.  
        (You do have a mouse pad, don't you?)



--------------------------------------------------------------------------



:THIS WEEK'S QUOTE:
===================

From Fenster's Harp
-------------------

  "The man who can smile when things go wrong, already has picked his
  scapegoat"!
                                            by R.M.Nixon



-------------------------------------------------------------------------
ST-REPORT Issue #52   SEPT. 12, 1988   (c)'88 APEInc. All Rights Reserved.
Reprint permission granted except where noted in the article. Any reprint
must include ST-Report and the author in the credits.  Views Presented 
herein are not necessarily those of ST-Report or of the Staff.  All items
and articles appearing in ST-REPORT are copywrite (c)APEInc.
-------------------------------------------------------------------------
