CLIM mail archive
[Prev][Next][Index][Thread]
Re: problems with 1.1 output records under incremental redisplay
> 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.
...
>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.
This is why I posted to clim@bbn.com. Lucid "support" is too slow for
people under the wire. They have patches for known bugs that they
won't release to us unless we go through the agony of tracking down
the existing bug, writing a test case, and submitting it. I was hoping
someone would run this through their bug-recognition pattern matcher
and save us the bureacracy.
People interested in the success of CLIM should pay attention to
complaints like these and do something instead of being defensive.
(Scott, I know it's not your problem, you just hit a hot button.)
> 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 ...
...
>DRAW-TEXT* is a graphics function, not a text function. The text
>function is WRITE-STRING.
See comment (above) -- write-string is unusable due to the prior bug.
References:
Main Index |
Thread Index