[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
moving windows to the back
- To: firstname.lastname@example.org
- Subject: moving windows to the back
- From: email@example.com
- Date: Wed, 15 Feb 95 19:01:46 -0500
- Cc: firstname.lastname@example.org
- Sender: email@example.com
I found something that could send a window to the back without using
the (Set-window-layer) command. There is a mac trap, called SendBehind
which will send a window to the back or behind another window,
and *this* doesn't call view-deactivate-event-handler. The final procedure
(defmethod view-deactivate-event-handler ((view procs-window))
(#_sendbehind (wptr view) (%null-ptr)))
And this works. One problem is that the procs-window is still hilighted
in the background, and I turned off the highlight after I moved it
back, but it got rehilighted by MCL again. I don't know. Maybe I should
change this to an :after method.
One thing, I wanted a cc-window to appear on top, when someone
clicked away from a specific window. (The cc-window is the command
input window, so when you're done with the procedures page (procs-window)
it would go back to the command center automatically)
I tried what someone suggested, which was to put an
(eval-enqueue (window-select cc-window)) in it, but I just got another
recursive bug with my windoid trying to be on top, vs. the cc-window.
I think I'll just leave it out, for now. :)
One thing that bugs me about the Mac Toolbox is that even when a window
is not active it can be hilighted. I'm not sure the reason for this but
it seems like a violation of UI if a background is left highlighted.
(except for a windoid) Why didn't they just lump these two functions?
Oh well, thanks for the help.
MIT Media Lab
Epistemology and Learning