CLIM mail archive


problems with 1.1 output records under incremental redisplay

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.)

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

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 ...

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!)

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?

Any help from the clim community is appreciated as well, as we are 
scheduled to try this system with users on Friday the 18th.
 Dan Suthers           | LRDC, room 505A     | 3939 O'Hara Street
 (412) 624-7036 office | University of Pittsburgh
 (412) 624-9149 fax    | Pittsburgh, PA 15260


Main Index | Thread Index