CLIM mail archive
[Prev][Next][Index][Thread]
Re: CLIM 1.1 erase-output-record ?
This is indeed a FAQ. You are getting bitten by the bug in
coordinate sorted sets. I don't know if there are any other
types of output records in clim 1.
jeff morrill
To: John Aspinall <jga@harlequin.com>
cc: clim@BBN.COM
Subject: Re: question on table-formatting + graphics
Reply-To: jmorrill@BBN.COM
Date: Fri, 17 Jun 1994 14:55:39 -0400
From: Jeff Morrill <jmorrill@BBN.COM>
From: John Aspinall <jga@harlequin.com>
Date: Fri, 17 Jun 1994 14:40:59 -0400
To: marilynb@seahorse.arc.nasa.gov
Cc: clim@BBN.COM
Subject: question on table-formatting + graphics
Cause of the problem: using the default type of output-record -
coordinate-sorted-sets. You're not really interfering with the table,
just confusing the output-record lookup *above* the table.
Coordinate-sorted-sets are assuming that no record inserted in the
history after the table will overlap the table. It's a bug.
Easy workaround (CLIM 2 only, alas): Use an r-tree-output-history for
the work-area pane.
(define-application-frame test-editor ()
(...)
(:command-table (top-level-test-ct))
(:panes
...
(work-area
:application
:default-text-style '(:fix :roman :normal)
:display-function 'display-structure
:output-record (make-instance 'r-tree-output-history) ;; <== !
:incremental-redisplay nil
:scroll-bars ':both))
)
Then it works for me. (Lispworks 3.2, our "Beta 7" CLIM 2.)
John
If we took all the money we've individually spent rediscovering this
bug, we could have quite a party. There is some bug in coordinate-sorted-sets
where the output records don't get sorted correctly. When that happens,
mouse sensitivity goes haywire and so does incremental redisplay.
I am dismayed that coordinate-sorted-sets are the default for panes.
Whenever I have reasonably tricky graphics, I always override the default.
jeff morrill
Follow-Ups:
References:
Main Index |
Thread Index