cmedley@wam.umd.edu (Charles Henry Medley) (05/12/91)
I have been working on what I hope to be a commercial product for quite some time, and what it does, running as an accessory, is steal the TRAP #5 vector. I have often thought about making the TRAP #5 code an AUTO .PRG, but decided against it for the sake of simplicity for the user. What it boils down to is that this TRAP #5 code needs to know if the user has changed resolutions from "Set Preferences" on the desktop. Since all of my code is legal under GEM (in fact, it counts on GEM!) I don't want to use any dangerous hacks. However, I've tried several methods and none work realiably (i.e., checking for new sizes of the desktop window when about to install a new trap handler, checking to see if the TRAP #5 is currently owned by me, etc...). Apparently, one source of my problem is that on a change in the resolution, the ST does do a warm boot, but it does not affect system vectors, like the various TRAP pointers or the hard drive vectors, etc... And my accessory needs to know when the accessories are being flushed so it can clear out, and when the system reloads ACCs, it can reinstall on the TRAP #5. Any help is appreciated.
kbad@atari.UUCP (Ken Badertscher) (05/17/91)
Desk accessories should not steal trap vectors. This is not to say that lots of DA's (desk accessories should not steal trap vectors) that are already out there don't take vectors, but (desk accessories should not steal trap vectors) it really isn't a recommended thing. Desk accessories, as we all know, are (desk accessories should not steal trap vectors) accessories, side-liners, assistants, and as such (desk accessories should not steal trap vectors) they don't warrant the same considerations (desk accessories should not steal trap vectors) as main-line applications. As Julian R. (hi, Julian!) has recently pointed out (desk accessories should not steal trap vectors), things that take vectors really belong in the AUTO folder. TSRs should be the ones (desk accessories should not steal trap vectors) setting up resources like this, and they should use the Cookie Jar to communicate with other programs. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>