CLIM mail archive
[Prev][Next][Index][Thread]

Avoiding delete-output-record-element error

    Date: Mon, 28 Oct 91 06:33:04 PST
    From: Curt Eggemeyer <curt@eraserhead.jpl.nasa.gov>

    I'm converting my software into CLIM, but I only wish to use the presentation
    aspects within the application frame construct. 
[...]

    My problem is this.  Whenever I invoke erase-output-record function on my own
    presentations, output-records, etc. , I hit the debugger in the
    delete-output-record-element in which CLIM thinks my presentations aren't
    there when they are  (I looked into the top-level-coordinate-sorted-set).
    My presentations are overlapping and I know CLIM is
    doing some of its own massaging of the display.  My display pane has
    incremental display off, but it seems CLIM is still massagging my presentation
    stuff.  How do I turn it off?  I am maintaining my own pointers to what is
    on the display and I wish to selectively erase and regenerate things on my
    own.  Is there some application-frame pane flag I need to set to tell CLIM
    that I will handle the output-record history?

I think that you may have found a bug in the "coordinate-sorted"
output record implementation.  A normal, scrolling, text-oriented CLIM
window stores its output records sorted by their Y coordinates.  This
makes for faster searching (e.g. during presentation highlighting),
since the search can be bounded.  However, there is one exception to
the "always sort by Y coordinates" rule, namely that overlapping
output records are stored in the order in which they were drawn.  This
is necessary in order to get replay to stack overlapping things
correctly.  Unfortunately, this exception has been known to confuse
parts of the code that always expect the records to be sorted by
Y-coordinate.

I can't find the bug just by looking at the code, and the simple cases
of overlapping records that I tried seemed to work OK.  If you can
supply a test case I will see what I can do.

Alternatively, you can try to work around this bug by bypassing the
coordinate-sorting feature.  To do this, evaluate the following form
(where WIN is assumed to refer to your application pane):

(setf (output-recording-stream-output-record win)
      (make-instance 'clim::linear-output-record))

This will cause your window to use a simpler output record type that
just stores its inferiors in a sequence in the order in which they
were added.  If this fixes your problem, then there is indeed a bug in
the coordinte-sorted stuff.  The only downside to this scheme is that
mouse sensitivity might be slower, since the records aren't sorted in
any particularly useful way.  We had always intended to supply more
output record types, including ones that sorted their inferiors in kD
or R tree structures.  Those would be better for randomly-arranged
graphical output.

0,,
References:
Main Index | Thread Index