Re: low-level system events

[slh@digitool.com (Steve Hain)]

At 2:52 PM 2/14/95, abegel@media.mit.edu wrote:
>How can I tell if my application has been sent to the background?

Try checking the value of *foreground*, perhaps in an *eventhook*
function or window-null-event-handler method. If you keep track of when
the value changes between non-nil and nil, you can tell when MCL
has been suspended or resumed.

>I'm doing some low-level assebly drawing stuff that I want to 
>disable if my application is not in the foreground. Right now, I do it
>when the window that I'm drawing in gets deactivated, but if I have
>a screen saver, the window isn't deactivated and will keep drawing
>over the screen saver!

As far as I know, screen savers don't "come to the foreground" like
applications, and therefore do not deativate windows. I believe they
just take over the WIndow Manager's grafport, and invalidate the entire
screen when they are deactivated. I don't know how you could check for
a screen saver running from MCL; perhaps someone else has a suggestion.

>Also, when you change color-depth using the Monitors control panel, 
>does it send out any apple events or low-level events that I can see? I need
>to change palettes for different color depths, and need to know when
>it has changed.
>
>I could check when lisp gets resumed (they would have had to run another
>program to change the color depth, and lisp would have gone into the
>background) but I don't know when this happens or when I can detect it, 
>either.
>

Check out the GDevice.lisp file in our MCL contributions site (
ftp.digitool.com, /pub/mcl/contrib) for some useful code to get
screen depths information.

To find out when MCL is suspended or resumed, try the method I suggested
above. MCL event-handling code looks for "app4" events and uses the
suspend/resume bit of the event message to set the value of *foreground*;
you can try something similar if you need tighter control of suspend/resume
processing.

Regarding earlier questions about selecting a particular window after
the front window is deactivated, try using eval-enqueue to queue up
a select-window request; this will ensure that built-in window management
processing completes before your intended action can occur. Alternatively,
you can try adding an :after method to a window's view-activate-event-handler
that uses set-window-layer to position another window directly behind it.

In general, however, instead of trying to modify the behavior of the window
system, it may be preferable to redesign your UI to use a hierarchy of
views, or windoids, or some combination of the two. But in any case, I
hope these suggestions are of some help.

- Steve Hain

Digitool, Inc.
______________________________________________________________________________
                          675 Massachusetts Avenue   Cambridge, MA 02139   USA
                              Internet: slh@digitool.com   AppleLink: digitool
                                         Tel: 617 441-5000   Fax: 617 576-7680