home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / lisp / mcl / 1585 < prev    next >
Encoding:
Text File  |  1992-11-13  |  4.7 KB  |  103 lines
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!bill@cambridge.apple.com
  2. From: bill@cambridge.apple.com (Bill St. Clair)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: parallel text dialog items
  5. Message-ID: <9211131636.AA15250@cambridge.apple.com>
  6. Date: 13 Nov 92 17:41:37 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 92
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. At 20:01 11/11/92 +0000, Christopher Owens wrote:
  12. >In <1992Nov9.172923.6367@midway.uchicago.edu> Tom McDougal <mcdougal@cs.uchicago.edu> writes:
  13. >
  14. >>>I want to have text appear simultaneously in two places within a
  15. >>>window.  A variant on the text-edit-dialog-item (from the examples
  16. >>>folder) would be fine, but I'm not sure how to pass the key-events
  17. >>>to multiple dialog items.  Several attempts so far have failed.
  18. >
  19. >Do you need the user to be able to type into either window?
  20. >
  21. >I'd suggest that you create two editable-text-dialog-items that share
  22. >a common buffer, by munging the "FREC" slots of the
  23. >editable-text-dialog-items. Since they now share a buffer, this
  24. >obviates the need for spoofing keystrokes to one dialog item when the
  25. >user types in the other.
  26. >
  27. >You'll still need to force an update of the second dialog item every
  28. >time the first is redrawn.
  29.  
  30. There is a documented way for two FRED-DIALOG-ITEM's to share a
  31. common buffer. It's not necessary to munge the FREC slot.
  32.  
  33. (let (et1)
  34.   (make-instance 'window
  35.     :view-size #@(200 210)
  36.     :window-type :document
  37.     :view-subviews (list (setq et1
  38.                                (make-instance 'fred-dialog-item
  39.                                  :view-position #@(5 5)
  40.                                  :view-size #@(190 90)
  41.                                  :dialog-item-text "Some text to start with"))
  42.                          (make-instance 'fred-dialog-item
  43.                            :view-position #@(5 100)
  44.                            :view-size #@( 190 90)
  45.                            :buffer (fred-buffer et1)))))
  46.  
  47. Unfortunately, this does not work quite right. When you type in one of
  48. the dialog items, the other one is not updated. Also, the :dialog-item-text
  49. given to the first one is erased as soon as the second item is created.
  50. These are both MCL bugs. I guess noone has yet tried sharing a buffer
  51. between two fred-dialog-item's. I have prepared a patch to fix this bug
  52. which will be part of patch 2 for MCL 2.0. If you want the patch before then,
  53. ask for "shared-fred-buffer-patch".
  54.  
  55. At 20:36 11/11/92 +0000, Tom McDougal wrote:
  56. >First, there was a biiiig mistake in my original code, which
  57. >should have been obvious.  See if you can spot it:
  58. >
  59. >>> (defclass twin-text-item (aligned-text-dialog-item)
  60. >>>   ((brother :accessor brother :initarg :brother 
  61. >>>             :type 'text-edit-dialog-item)))
  62. >>> 
  63. >>> (defmethod key-event-handler :after ((self twin-text-item) char)
  64. >>>   (key-event-handler (brother self) char))
  65. >
  66. >See it?  'key-event-handler' should have been
  67. >'view-key-event-handler'.  
  68. >
  69. >Given that correction, the code above works for instances of
  70. >editable-text-dialog-item, but not for instances of
  71. >text-edit-dialog-item (defined in the examples folder).  In the latter
  72. >case, duplicates of each keystroke end up going to the same view.
  73. >Why?
  74. >
  75. >It seems as though keystrokes are always handled by the window's
  76. >key-event-handler.  So the following correction works:
  77. >
  78. > (defmethod view-key-event-handler :after ((self twin-text-item) char)
  79. >   ; change the window's key event handler to BROTHER's handler
  80. >   (set-key-event-handler (view-container self)
  81. >                          (key-event-handler (brother self)))
  82. >   ; process the keystroke again
  83. >   (view-key-event-handler (brother self) char)
  84. >   ; restore SELF's handler as window's key event handler
  85. >   (set-key-event-handler (view-container self) (key-event-handler
  86. >self)))
  87.  
  88. Youve found the secret. Once upon a time, each text-edit-dialog-item
  89. had its own TextEdit record. One of us realized that it was only necessary
  90. to have one TextEdit record that everyone could share. Since this reduces
  91. consing in the Mac heap, it's part of the TEXT-EDIT-DIALOG-ITEM implementation.
  92. SET-KEY-EVENT-HANDLER calls VIEW-ACTIVATE-EVENT-HANDLER which changes the
  93. shared TextEdit record to point at the activated view.
  94.  
  95. >
  96. >All suggestions have involved using editable-text-dialog-items, which
  97. >I will use if necessary, but the whole reason for going to text-edit-
  98. >dialog-items was to avoid the extra bulk of fred dialog items.
  99.  
  100. This will make sense once a small application generator exists for MCL.
  101. Until then (which will be a while), there is no (easy) way to purge Fred from
  102. your world, so you won't lose anything by using it.
  103.