[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
making presentation actions work when no input expected
Date: Fri, 24 Feb 89 11:07:59 EDT
From: cogen@XN.LL.MIT.EDU (David Cogen)
I have used DEFINE-PRESENTATION-ACTION to perform a side effect when the mouse
is clicked in certain windows, under certain conditions. (The windows are panes
of a frame; the effect is to change the frame configuration so the clicked-in
pane is the large pane. But this is only allowed under certain conditions.)
So I defined a presentation action roughly as follows:
:TESTER ((IGNORE &KEY GESTURE WINDOW)
(AND (EQ GESTURE :MIDDLE)
(TYPEP WINDOW 'my-window-pane-type)
(IGNORE &KEY WINDOW)
This works as long as the currently selected window is accepting input. The T
from-type and to-type guarantees that it will work for any kind of input
context. The :BLANK-AREA T means that I don't have to mouse on a presentation
for it to work. This is all as I want it. The problem is, if the selected window
is not accepting input, clicking the mouse has no effect. But double-click-right
always brings up the system menu, even when the selected window is not accepting
input. How does this work? I wondered. I looked at the source; it seems like I
am doing the same thing. So how can I make it work?
Shift-Mouse-Right (or double-click Mouse-Right if you use that) is
handled specially by the system and does not go through DW.
You can think of presentation translators as taking place in the "eval"
part of the "read-eval-print" loop (or you might think of them as acting
like commands in the CP) , and presentation actions as taking place in
the "read" part (they actually run in the input editor). No translation
of any kind takes place when the process is not waiting for input.
Do I even want to define a presentation action? Or must I implement this at a
lower level, like a method for :MOUSE-CLICK?
You could do that, yes. It would not be unreasonable for DW to support
simple asynchronous actions like this.
Another question: What is the significance of the keyword GESTURE in the tester
That's a good question which I don't offhand know the answer to.
Doesn't the tester run before any buttons are clicked?
Yes, it does.
So how can it
know what to set GESTURE to?
Beats me. Don't bother including it in your tester at all.