Unruly buttons and tables

[ST.CLAIR@AppleLink.Apple.COM (St. Clair, William)]

   From: Luke Hohmann <hohmann@csmil.umich.edu>
   Message-Id: <9105231334.AA08857@csmil.umich.edu>
   To: info-macl@cambridge.apple.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.
 
   [Code omitted]
 
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:
 
-------------------------------------------------------------------------
 
; table-activate-patch.lisp
;
; Patch makes the scroll bars be activated properly for
; *table-dialog-item*'s
; This fixes a bug in the System 6 list manager.
 
(in-package :ccl)
 
(require :records)
(require :traps)
 
(let ((*warn-if-redefine* nil))
 
(defobfun (dialog-item-activate-event-handler *table-dialog-item*) ()
  (let* ((dims (table-dimensions))
         (vdims (visible-dimensions))
         (handle dialog-item-handle)
         (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))))
 
)