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 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... 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.] 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 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 ) <[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 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. 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... <[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> <[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] <[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 yes, I tend to agree. Sorry about that comment a second ago sounding a bit huffy.. 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. 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? 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? 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? 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? 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. OK. 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. <[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! 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. I did, months ago.... <[John @ Atari] TOWNS> Please leave me Mail. I will make sure something gets to you. Thanks ! 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. zounds good. 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> How ya gonna EXPOSE yourself, NEIL?? <[John @ Atari] TOWNS> I am glad you and your Boyfriend enjoy your Atari Computer 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. -------------------------------------------------------------------------