marco@sys6626.bison.mb.ca (Marco) (05/23/91)
Does anyone happen to have any code on sensing if there's a GEM window on
the screen from within a stay-resident (auto folder) type program. Maybe
there's a C function?
/-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\
*John Perry; Voice #-204/783-0812; Internet: *
*marco@sys6626.bison.mb.ca *
*---------------------------------------------------------*
* "It is an old maxim of mine that when you have excluded *
* the impossible, whatever remains, however improbable, *
* must be the truth." -Sir Arthur Conan Doyle *
\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/23/91)
marco@sys6626.bison.mb.ca (Marco) writes: >Does anyone happen to have any code on sensing if there's a GEM window on >the screen from within a stay-resident (auto folder) type program. Maybe >there's a C function? You could do this from a DA by calling wind_get(WF_TOP...). If there is a GEM window, there must be a top window. If there is none, you won't get a top window handle other than 0 (desktop window). ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus Brod@wue.maus.de ----------------------------------------------------------------------
uace0@menudo.uh.edu (Michael B. Vederman) (05/23/91)
In article <1991May23.102120.938@informatik.uni-erlangen.de> csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >marco@sys6626.bison.mb.ca (Marco) writes: > >>Does anyone happen to have any code on sensing if there's a GEM window on >>the screen from within a stay-resident (auto folder) type program. Maybe >>there's a C function? > >You could do this from a DA by calling wind_get(WF_TOP...). If there is >a GEM window, there must be a top window. If there is none, you won't >get a top window handle other than 0 (desktop window). > >---------------------------------------------------------------------- >Claus Brod, Am Felsenkeller 2, Things. Take. Time. >D-8772 Marktheidenfeld, Germany (Piet Hein) >csbrod@medusa.informatik.uni-erlangen.de >Claus Brod@wue.maus.de >---------------------------------------------------------------------- There is also a section of lower memory used by the AES which tracks windows and their various attributes (including whether or not they are open). This area, however, is not documented, is very ROM dependent, and would be called an _illegal_ method of determining such by Atari Corp. If you are a hacker, you might want to mess with this, otherwise, a TSR can never find out the answer to such a question.... Although, one might install a TRAP #2 wedge, and perform a wind_get call at some safe time. Don't write me asking for more info! I will ignore any request for further details. I've probably said more than my friends at Atari would like... - mike -- ------------------------------------------------------------------------------ Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274 ------------------------------------------------------------------------------ Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others
micro@imada.ou.dk (Klaus Pedersen) (05/25/91)
uace0@menudo.uh.edu (Michael B. Vederman) writes: >In article <1991May23.102120.938@informatik.uni-erlangen.de> csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >>marco@sys6626.bison.mb.ca (Marco) writes: >> >>>Does anyone happen to have any code on sensing if there's a GEM window on >>>the screen from within a stay-resident (auto folder) type program. Maybe >>>there's a C function? >> <Claus gives a simple solution, w. a team of a TSR and ACC > >>Claus Brod, Am Felsenkeller 2, Things. Take. Time. >There is also a section of lower memory used by the AES which tracks >windows and their various attributes (including whether or not they are >open). Yes, ofcause there is! All programs have vars that keep track of what they are doing! >This area, however, is not documented, is very ROM dependent, and would >be called an _illegal_ method of determining such by Atari Corp. If Atari ever told where these things were and the meaning of the variables, It would probaly mean that Atari not intended to upgrade GEM/TOS anymore, so lets hope, that it never becomes legal... >If you are a hacker, you might want to mess with this, otherwise, a TSR >can never find out the answer to such a question.... Although, one might NO YOU WOULD NOT!! WE DON'T NEED MORE BAD SOFTWARE!!! There is not enough hacker in you - a real hacker would not spend hours, trying to figure out what a bit in os-private-area is doing. A real hacker would monitor wind_close,wind_new,wind_open. (and tell everybody that it don't work from the desktop). >Don't write me asking for more info! I will ignore any request for further >details. I've probably said more than my friends at Atari would like... Real friends tell you when to stop! -It is very bad pratice to use anything, that make Atari look bad when they release something good (new Tos,Gdos,filing system,...). Klaus, micro@imada.ou.dk >- mike
uace0@menudo.uh.edu (Michael B. Vederman) (05/25/91)
Klaus Pederson writes:
NO YOU WOULD NOT!! WE DON'T NEED MORE BAD SOFTWARE!!!
There is not enough hacker in you - a real hacker would not spend hours,
trying to figure out what a bit in os-private-area is doing. A real hacker
would monitor wind_close,wind_new,wind_open. (and tell everybody that it
don't work from the desktop).
--------------
Sometimes to get a very desirable prgram running, you have to break the
rules. Sometimes to get the features people want, you have to do whatever
it takes to get it done.
Then you just add the following to your documentation:
"This program uses several undocumented memory locations. These locations
are not documented and are subject to change in TOS revisions. We will
continue to support this product and make any changes required due to TOS
revisons resulting in the changing of these undocumented locations. We will
also provide updates due to such circumstances for free or at a minimal
shipping cost."
This is verbatim from our DC Desktop manual. We also list what trap vectors
we monitor and modify/use.
Our recently posted DC Topper also has a strong warning about its use of
undocumented TOS/GEM structures (including window resources and tracking).
Many, many people have been asking for a program like DC Topper (which
tops the window under the mouse automatically) since I've had access to the
net. I'd say the 'bad programming' was worth it. It was the fourth best
download on GEnie for April/May and has been widely praised by many...
Caveat emptor - Let the buyer beware.
We are very deliberate in letting people know that we break the rules in
order to give them the feature(s) they demanded.
It is an individuals choice whether they wish to benefit from such a
program. Otherwise, somethings would never be done.
- mike
--
------------------------------------------------------------------------------
Double Click Me | Double Click Software | P.O. Box 741206 | Houston, Tx, 77274
------------------------------------------------------------------------------
Voice: (713)977-6520 | DC DESKTOP | DC FORMATTER | DC UTILITIES | and others