CLIM mail archive

[Prev][Next][Index][Thread]

problems with 1.1 output records under incremental redisplay



   Date: Mon, 14 Feb 1994 17:07:37 -0500 (EST)
   From: Daniel D Suthers <suthers+@pitt.edu>

   CLIM 1.1, Lucid 4.something

   We are experiencing a number of problems with incremental redisplay,
   some of which are tempting us to rewrite functionality which the CLIM
   bill of sale says we were supposed to get.  Could Lucid please check
   these against your record of known bugs & patches and send us any
   relevant patches.

   ----------------------------------------------------------------------
   Improper redisplay of overlapping or "linked" output records:

   Context: graphical output records that overlap or link, for example: 

	    ---------------                 --------------------
	    | A           |                 | B                |
	    |   -----     |                 |   ----------     |
	    |   | C |     |--------L--------|   | D      |     |
	    |   -----     |                 |   ----------     |
	    ---------------                 --------------------

   (There are 5 presentations, one for each of A, B, C, D, and L. L is a
   line that links the outer boxes.)

   Problem: If we move one of the boxes (A or B), the other box is not
   updated and its contents are not visible. For example, if you move A,
   then D disappears; if you then move B, D will reappear but C will
   disappear! This only happens when another output record, L, overlaps
   them. We get similar problems with two boxes that overlap at a corner.

   This problem did not occur before we started using incremental
   redisplay. (Same for everything below.)

I can't offer any help without a small, reproducible failing test
case.  I have programsd that do similar things in CLIM 2.0 that work
properly, so it could either be a bug that has since been fixed in
CLIM 2.0, a bug in your code, or you have discovered a new bug.

   ----------------------------------------------------------------------
   Interaction of output records with text created by filling-output:

   Context: Text display using indenting-output & filling-output to write
   blocks of text at various positions (e.g., inside graphical boxes such
   as those shown above).

   Problem: It worked fine (although slow) until we converted to use
   updating-output, whereupon any output record that happened to be to
   the left of the text got moved to extreme negative coordinates. Our
   own data structures did not change: the only change was in the output
   record left, right, top, bottom.  For example, in the diagram above
   if D was a text then A would go flying off to far upper left (e.g.
   from positions in the positive 200's to positions in the negative
   600's). 

   We subsequently determined that this has something to do with
   unselectable whitespace inserted by indenting-output in the space in
   which the moved record formerly resided. This only happened when using
   write-string: when we used clim:draw-text* the output records were no
   longer moved, presumably because there was no longer any output in the
   region to the left where the other record resided. However ...

Same deal -- we'll need a failing test case.

   ----------------------------------------------------------------------
   Write-string vs. draw-text* for filling-output:

   Clim:filling-output does not operate on clim:draw-text* output! So
   in order to avoid throwing other records into hyperspace we had to
   write our own filling-output, whereupon we discovered other problems.

   (It seems odd that a text writing function provided as part of a 
   software package would not work with text formatting macros
   provided with the same software package!)

DRAW-TEXT* is a graphics function, not a text function.  The text
function is WRITE-STRING.

   ----------------------------------------------------------------------
   Oversized output records created by draw-text*:

   When we call clim:draw-text with :start and :end to write a portion of
   a string, the output record that is created is too long (according to
   my programmer, long enough to include the entire string). That is,
   selectable regions overflow far to the right. Does draw-text* ignore
   :start and :end in deciding how big the output record should be?

I didn't try this, since I don't have CLIM loaded right now.

Follow-Ups: References:

Main Index | Thread Index