Re: parallel text dialog items

[bill@cambridge.apple.com (Bill St. Clair)]

At 20:01 11/11/92 +0000, Christopher Owens wrote:
>In <1992Nov9.172923.6367@midway.uchicago.edu> Tom McDougal <mcdougal@cs.uchicago.edu> writes:
>
>>>I want to have text appear simultaneously in two places within a
>>>window.  A variant on the text-edit-dialog-item (from the examples
>>>folder) would be fine, but I'm not sure how to pass the key-events
>>>to multiple dialog items.  Several attempts so far have failed.
>
>Do you need the user to be able to type into either window?
>
>I'd suggest that you create two editable-text-dialog-items that share
>a common buffer, by munging the "FREC" slots of the
>editable-text-dialog-items. Since they now share a buffer, this
>obviates the need for spoofing keystrokes to one dialog item when the
>user types in the other.
>
>You'll still need to force an update of the second dialog item every
>time the first is redrawn.

There is a documented way for two FRED-DIALOG-ITEM's to share a
common buffer. It's not necessary to munge the FREC slot.

(let (et1)
  (make-instance 'window
    :view-size #@(200 210)
    :window-type :document
    :view-subviews (list (setq et1
                               (make-instance 'fred-dialog-item
                                 :view-position #@(5 5)
                                 :view-size #@(190 90)
                                 :dialog-item-text "Some text to start with"))
                         (make-instance 'fred-dialog-item
                           :view-position #@(5 100)
                           :view-size #@( 190 90)
                           :buffer (fred-buffer et1)))))

Unfortunately, this does not work quite right. When you type in one of
the dialog items, the other one is not updated. Also, the :dialog-item-text
given to the first one is erased as soon as the second item is created.
These are both MCL bugs. I guess noone has yet tried sharing a buffer
between two fred-dialog-item's. I have prepared a patch to fix this bug
which will be part of patch 2 for MCL 2.0. If you want the patch before then,
ask for "shared-fred-buffer-patch".

At 20:36 11/11/92 +0000, Tom McDougal wrote:
>First, there was a biiiig mistake in my original code, which
>should have been obvious.  See if you can spot it:
>
>>> (defclass twin-text-item (aligned-text-dialog-item)
>>>   ((brother :accessor brother :initarg :brother 
>>>             :type 'text-edit-dialog-item)))
>>> 
>>> (defmethod key-event-handler :after ((self twin-text-item) char)
>>>   (key-event-handler (brother self) char))
>
>See it?  'key-event-handler' should have been
>'view-key-event-handler'.  
>
>Given that correction, the code above works for instances of
>editable-text-dialog-item, but not for instances of
>text-edit-dialog-item (defined in the examples folder).  In the latter
>case, duplicates of each keystroke end up going to the same view.
>Why?
>
>It seems as though keystrokes are always handled by the window's
>key-event-handler.  So the following correction works:
>
> (defmethod view-key-event-handler :after ((self twin-text-item) char)
>   ; change the window's key event handler to BROTHER's handler
>   (set-key-event-handler (view-container self)
>                          (key-event-handler (brother self)))
>   ; process the keystroke again
>   (view-key-event-handler (brother self) char)
>   ; restore SELF's handler as window's key event handler
>   (set-key-event-handler (view-container self) (key-event-handler
>self)))

Youve found the secret. Once upon a time, each text-edit-dialog-item
had its own TextEdit record. One of us realized that it was only necessary
to have one TextEdit record that everyone could share. Since this reduces
consing in the Mac heap, it's part of the TEXT-EDIT-DIALOG-ITEM implementation.
SET-KEY-EVENT-HANDLER calls VIEW-ACTIVATE-EVENT-HANDLER which changes the
shared TextEdit record to point at the activated view.

>
>All suggestions have involved using editable-text-dialog-items, which
>I will use if necessary, but the whole reason for going to text-edit-
>dialog-items was to avoid the extra bulk of fred dialog items.

This will make sense once a small application generator exists for MCL.
Until then (which will be a while), there is no (easy) way to purge Fred from
your world, so you won't lose anything by using it.