home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / next / programm / 8242 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  4.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!doug.cae.wisc.edu!umn.edu!mmm.serc.3m.com!mmc.mmmg.com!timbuk.cray.com!raistlin!uc.msc.edu!noc.msc.net!news.gac.edu!news!scott
  2. From: scott@nic.gac.edu (Scott Hess)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Problem/solution for some Text object RTFD weirdness.
  5. Date: 21 Jan 93 02:59:55
  6. Organization: Is a sign of weakness
  7. Lines: 94
  8. Distribution: world
  9. Message-ID: <SCOTT.93Jan21025955@nic.gac.edu>
  10. NNTP-Posting-Host: nic.gac.edu
  11.  
  12. I've had a recurrent problem which manifests when loading streams
  13. of RTFD data into a Text object.  This bug manifests when identical
  14. code is run under both NS2.1 and NS3.0 - though I cannot vouch for
  15. the new RTFD-specific code in NS3.0 (there are new methods integral
  16. to the Text object that might not show this problem).  More than
  17. likely, this post will have no use to anyone, but one never knows ...
  18.  
  19.  
  20.  
  21. Problem
  22.  
  23. In essence, I've got an Attachment class which is capable of reading
  24. tiff or eps data into an NXImage.  I do:
  25.  
  26.     [Text registerDirective:"NeXTGraphic" forClass:[Attachment class]];
  27.  
  28. to register the class for NeXTGraphic directive.  For the _most_
  29. part it works, but sometimes there are problems.
  30.  
  31. The problems occur while in the Text method -readRichText:.
  32. Periodically, my Attachment instances will be called on to draw
  33. themselves _twice_.  The first time through, the position of the
  34. graphic is recorded as an odd x,y value, such as {0, 0}, even when
  35. the graphic is far into the document.  Sometimes, though, I find
  36. that I am being passed totally wacko data, such as:
  37.  
  38. Stuart? rect=={{ 0.000000, -755578637259143230000000.000000}, { 100.000000, 96.000000}}
  39.  
  40. and:
  41.  
  42. Stuart? rect=={{ 0.000000, NaN}, { 77.000000, 20.000000}}
  43.  
  44. The problem seems to degrade over time, with the first couple loads
  45. being alright, but later ones having more chances of being screwed
  46. up.
  47.  
  48. Also, by running the program with -NXShowAllWindows, I noticed that
  49. more images were being asked to display than actually fit within
  50. the visible area.  To be more precise, when the Text first called
  51. the Attachment object to display themselves, more attachments were
  52. displayed than were displayed when it called them each a second
  53. time.  Running Edit with -NXShowAllWindows and loading the same
  54. files demonstrated that Edit _only_ displayed the images which were
  55. actually within the visible area.  It did _not_ display any of the
  56. later images in the file until they entered the visible area.
  57.  
  58. Beyond the basic _weirdness_ of this problem, there lurks a bigger
  59. problem.  If you send the image to the windowserver with these bad
  60. values in it, things start to get wedged, I believe in the client
  61. library, and eventually my program falls off the deep end and dumps.
  62. No good!
  63.  
  64. My first approach to fixing this problem was to restrict the
  65. coordinates to "sane" values which I knew to be workable.
  66. Unfortunately, this apparently addressed the symptom _not_ the
  67. cause.  In some cases, I was still getting segmentation faults, so
  68. it seems that the problem was deeper than I first thought.
  69.  
  70.  
  71.  
  72. Solution
  73.  
  74. After quite a large amount of sleuthing, it occurred to me to look
  75. at another program I have which uses the same code, and see if it
  76. ever has the problem.  Nope.  The one difference I could find
  77. between the programs was that in one case, the Text object being
  78. read into was _always_ clean, with no text in it.  In the problem
  79. case, the Text object may already contain text, and possibly
  80. attachments.  The program now seems to work if I first do
  81. [aText setText:""] before doing the [aText readRichText:aStream],
  82. so apparently that was the problem.  With the code structured that
  83. way, the attachments are no longer displayed twice except when
  84. necessary (for instance, when scrolling).  Also, the extra images
  85. that were previously being displayed are no longer displayed until
  86. visible.
  87.  
  88.  
  89.  
  90. Summary
  91.  
  92. Asking the Text object to read new RTFD data while there is currently
  93. RTFD data in the Text object is a recipe for disaster.  Apparently,
  94. the Text object does not correctly remove all of the old information,
  95. and attempts to read in the new information in the context of the
  96. old.  In order to prevent this, first clear the Text using -setText:
  97. and then read the new RTFD data.
  98.  
  99. Note that this problem does _not_ affect regular RTF data without
  100. attachments.
  101.  
  102. Hope this can be of some help to someone out there,
  103. --
  104. scott hess <shess@ssesco.com>                        <To the BatCube, Robin>
  105. 12901 Upton Avenue South, #326  Burnsville, MN 55337 (612) 895-1208 Anytime!
  106.