UUCJEFF@ECNCDC.BITNET (03/19/88)
Is there any definitive book on what you can or can't do when writing desk accessories? There is a little bit in the MWC Version 2.00 docs, and they have an example, along with acskel.c from the developer's kit. But I would like to know how far you can deviate from those basic skelatins. For instance, I would like to be able to use string writting functions in which you can do a newline and the text will scroll up without having to rewrite each line. That pretty much precludes the use of windows, which seems to be the structural backbone of desk accessories. Also, if I were to replace the MIDI drivers, are there any thoughts on how I can handle the hey don't disappear with the program that loads the routines and revectors the interrupt handles. Any help is appreciated, Jeff Beer UUCJEFF@ECNCDC.BITNET
achowe@watmsg.waterloo.edu (CrackerJack) (03/22/88)
>Is there any definitive book on what you can or can't do when writing >desk accessories? There is a little bit in the MWC Version 2.00 docs, >and they have an example, along with acskel.c from the developer's kit. >But I would like to know how far you can deviate from those basic >skelatins. For instance, I would like to be able to use string writting >functions in which you can do a newline and the text will scroll up without >having to rewrite each line. That pretty much precludes the use of windows, >which seems to be the structural backbone of desk accessories. Well, as an on going exercise, I've writing my own shell program that comes in two forms - as a .PRG and a .ACC. I had the idea to do the ACC version too because it was the only why at the time I could think to autoload a GEM program. I soon found out the following problems with ACC programs... o You can NOT execute a GEM program using Pexec from an ACC. It seems that windows, desktop and menu resources just go NUTS. Maybe there is a way but it won't be standard. o You can NOT hide the menu bar from a ACC because you can't find the root of the object tree with all the resources. This means if you use a text screen and just try and do a form_dail () to redraw the desktop on exit you'll find that the menu bar is missing BUT active. Of course if when you exit from a PRG the whole desktop is restored - no problem. Grrrr! + To solve this problem I took the example of the VT52 emulator which is an ACC that handled text mode and screen rewrite just fine. How could Atari get away with it and not tell anyone? Well I spent about 7 hrs one night using SID to trace through the emulator ACC to find the method (this was before DISTOMWC.PRG). I've had plenty of practice using ZSID and DDT from my CP/M days doing this sort of learn without source. It was a pain (especially at 03.00 in the morn) but I found out that the emulator cheated. It saved the contents of video RAM that held the menu bar some where else to be later restored. Grrr Woof!!! Will I bagged the code and now it is part of my ACCSTART.S and other .S goodies I use. Well I now have the ACC shell on some disks where a shell is handy. It still is very simple lacking a full cp command. But if your like me you hate to exit a PRG to do cp, df, mf or ls commands. For the rest of you who are interested and saying where is it now that I've spilt the beans. You'll have to wait till I finish implementing the basics like - cp, fgrep, 10 line history, stty, set, setenv, and everything else. When I think I've done enough I'll pass around the ACC and PRG. I have some .S stuff I wrote that people might like which I'll passout on request. -- Anthony C. Howe achowe@watmsg.waterloo.edu "The definition of flying: throwing yourself at the ground and missing." - Douglas Adam's "Life, the Universe and Everything"
apratt@atari.UUCP (Allan Pratt) (03/22/88)
From article <8803190107.AA03238@ucbvax.Berkeley.EDU>, by UUCJEFF@ECNCDC.BITNET: > For instance, [in an accessory] I would like to be able to use string > writing functions in which you can do a newline and the text will scroll > up without having to rewrite each line. That pretty much precludes the > use of windows, which seems to be the structural backbone of desk > accessories. You can do it -- but you have to take over the screen. The VT52 emulator is a perfectly legal desk accessory. When you open it, it clears the screen and uses the alpha text output functions of the BIOS. When you hit UNDO to leave it, it clears the screen again and sends the desktop a redraw message so it'll all get redrawn. (At least, that's what I *think* it does.) As long as you don't do any event calls, your accessory will be the only process running. All the processor sharing in the AES between the DA's and the mainline task are done through the event manager. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
dclemans@mntgfx.mentor.com (Dave Clemans) (03/23/88)
You can do "vt52" style graphics in a desk accessory; look at the terminal emulator desk accessory from Atari. The only thing that you have to do "special" is to arrange to get the screen restored when the desk accessory exits. "form_dial(3,<x,y,w,h for full screen>)" will get most things redrawn; you might have to manually save and restore the part of screen memory that holds the menu bar. dgc
achowe@watmsg.waterloo.edu (CrackerJack) (03/24/88)
>> For instance, [in an accessory] I would like to be able to use string >> writing functions in which you can do a newline and the text will scroll >> up without having to rewrite each line. That pretty much precludes the >> use of windows, which seems to be the structural backbone of desk >> accessories. > >You can do it -- but you have to take over the screen. The VT52 emulator >is a perfectly legal desk accessory. When you open it, it clears the >screen and uses the alpha text output functions of the BIOS. When you >hit UNDO to leave it, it clears the screen again and sends the desktop >a redraw message so it'll all get redrawn. (At least, that's what I >*think* it does.) As in my previous note on this, when I traced through the emulator they did two things which I now do. First they save the video memory that the menu line occupies, then on exit they restore this and do a form_dial to restore the rest of the desktop screen. Oh. Also they turn the mouse off during text mode. This might be something you could add to the NEW ROMs, a way to store or turn off the menu bar and back again. -- Anthony C. Howe achowe@watmsg.waterloo.edu "The definition of flying: throwing yourself at the ground and missing." - Douglas Adam's "Life, the Universe and Everything"
Thomas_E_Zerucha@cup.portal.com (03/26/88)
>You have to take over the screen...
But you have to save the Menu Bar image yourself - that is NOT redrawn with
any GEM AES call that I have found. In my Emulator revision (Transfer 1.27)
I had to do that (copy from the screen to a buffer, clear and use the screen,
then redraw the menubar and issue the form_???? call to redraw everything
else).