[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unruly buttons and tables
- To: HOHMANN@CSMIL.UMICH.EDU
- Subject: Unruly buttons and tables
- From: ST.CLAIR@AppleLink.Apple.COM (St. Clair, William)
- Date: 24 May 91 21:08 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM
From: Luke Hohmann <email@example.com>
Subject: problems with disabled default buttons and sequence-dialog-items
Date: Thu, 23 May 91 09:34:37 -0400
1. Default Buttons and the return key...
We have found the following problems with the default button of
a window. The problems are is as follows: If you have a
disabled button that is the default button for a window, clicking
on the button does nothing but pressing the return key executes
the dialog-item-action associated with the button. If there
is no dialog-item-action associated with the return key, pressing
the return key first activates the button such the mouse can now
be used within the button.
Here is a tiny sample of code that demonstrates this problem.
This is a bug in the window-key-event-handler for the *dialog* class.
The easiest way to get around it is to do the following whenever you
disable the default button for a dialog:
(ask dialog (setq ccl::default-button-iv nil))
And the following when you reenable it:
(ask dialog (setq ccl::default-button-iv button))
2. Activating the scroll bars automatically
We have a sequence-dialog-item that displays a trace of the Pascal
program as it executes. This window is updated while the program
is running, regardless if this window is the active window. The
sequence-dialog-item has enough room for about 7 entries. Even
a simple program will create more than 7 entries.
Let's assume that we have added 15 entries to the dialog-item
(through calls to 'set-table-sequence). We would expect the dialog
item to have scroll bars displayed when it is activated, but the
scroll bars are only displayed if you click on the mouse and try to
scroll past the window. This is rather annoying, and in our first
few tests with the high school students they did not understand that
to be able to scroll the window they had to "try" to scroll the
window first. The real confusion lies if you have just enough
dialog items in the window to fill it but not scroll it. You are
left wondering if the window will scroll because there are a lot
of dialog items or ????
Please advise if anyone has some code or better interface techniques
to manage this problem.
This is a bug in the System 6 list manager. This bug is fixed in
System 7. The following patch should fix the problem:
; Patch makes the scroll bars be activated properly for
; This fixes a bug in the System 6 list manager.
(let ((*warn-if-redefine* nil))
(defobfun (dialog-item-activate-event-handler *table-dialog-item*) ()
(let* ((dims (table-dimensions))
(vscroll (rref handle :list.vscroll))
(hscroll (rref handle :list.hscroll)))
(_LActivate :word -1 :ptr dialog-item-handle)
(when (and hscroll (> (point-h dims) (point-h vdims)))
(_HiliteControl :ptr hscroll :word 0))
(when (and vscroll (> (point-v dims) (point-v vdims)))
(_HiliteControl :ptr vscroll :word 0))))