🚀 go-pugleaf

I've had a recurrent problem which manifests when loading streams
of RTFD data into a Text object.  This bug manifests when identical
code is run under both NS2.1 and NS3.0 - though I cannot vouch for
the new RTFD-specific code in NS3.0 (there are new methods integral
to the Text object that might not show this problem).  More than
likely, this post will have no use to anyone, but one never knows ...



Problem

In essence, I've got an Attachment class which is capable of reading
tiff or eps data into an NXImage.  I do:

    [Text registerDirective:"NeXTGraphic" forClass:[Attachment class]];

to register the class for NeXTGraphic directive.  For the _most_
part it works, but sometimes there are problems.

The problems occur while in the Text method -readRichText:.
Periodically, my Attachment instances will be called on to draw
themselves _twice_.  The first time through, the position of the
graphic is recorded as an odd x,y value, such as {0, 0}, even when
the graphic is far into the document.  Sometimes, though, I find
that I am being passed totally wacko data, such as:

Stuart? rect=={{ 0.000000, -755578637259143230000000.000000}, { 100.000000, 96.000000}}

and:

Stuart? rect=={{ 0.000000, NaN}, { 77.000000, 20.000000}}

The problem seems to degrade over time, with the first couple loads
being alright, but later ones having more chances of being screwed
up.

Also, by running the program with -NXShowAllWindows, I noticed that
more images were being asked to display than actually fit within
the visible area.  To be more precise, when the Text first called
the Attachment object to display themselves, more attachments were
displayed than were displayed when it called them each a second
time.  Running Edit with -NXShowAllWindows and loading the same
files demonstrated that Edit _only_ displayed the images which were
actually within the visible area.  It did _not_ display any of the
later images in the file until they entered the visible area.

Beyond the basic _weirdness_ of this problem, there lurks a bigger
problem.  If you send the image to the windowserver with these bad
values in it, things start to get wedged, I believe in the client
library, and eventually my program falls off the deep end and dumps.
No good!

My first approach to fixing this problem was to restrict the
coordinates to "sane" values which I knew to be workable.
Unfortunately, this apparently addressed the symptom _not_ the
cause.  In some cases, I was still getting segmentation faults, so
it seems that the problem was deeper than I first thought.



Solution

After quite a large amount of sleuthing, it occurred to me to look
at another program I have which uses the same code, and see if it
ever has the problem.  Nope.  The one difference I could find
between the programs was that in one case, the Text object being
read into was _always_ clean, with no text in it.  In the problem
case, the Text object may already contain text, and possibly
attachments.  The program now seems to work if I first do
[aText setText:""] before doing the [aText readRichText:aStream],
so apparently that was the problem.  With the code structured that
way, the attachments are no longer displayed twice except when
necessary (for instance, when scrolling).  Also, the extra images
that were previously being displayed are no longer displayed until
visible.



Summary

Asking the Text object to read new RTFD data while there is currently
RTFD data in the Text object is a recipe for disaster.  Apparently,
the Text object does not correctly remove all of the old information,
and attempts to read in the new information in the context of the
old.  In order to prevent this, first clear the Text using -setText:
and then read the new RTFD data.

Note that this problem does _not_ affect regular RTF data without
attachments.

Hope this can be of some help to someone out there,
--
scott hess <shess@ssesco.com>                        <To the BatCube, Robin>
12901 Upton Avenue South, #326  Burnsville, MN 55337 (612) 895-1208 Anytime!