Copy Link
Add to Bookmark
Report
Silicon Times Report Issue 0052
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 po
ssible 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.
-------------------------------------------------------------------------
