Re: NSTextField problems

[Enrico Sersale]

On Tue, 28 Jan 2003, Alexander Malmberg wrote:

> Enrico Sersale wrote:
> [snip]
> > Ok, now cliking in a NSTextField doesn't crash the app anymore, but:
> >
> > - after the first mouseDown:
> >
> > 1) the text dishappears.
> >
> > 2) I get a:
> >  -[NSLayoutManager(layout)
> > rectArrayForGlyphRange:withinSelectedGlyphRange:inTextContainer:rectCount:]:
> > invalid text container
> [snip]
>
> I've been able to reproduce this, and I've tracked it down to the cell
> not being tall enough for the text that's in it. In the case where I
> could reproduce it (the 'To' field in the print panel), the cell is 13.5
> points tall, but the text is 14 points tall. The easy way to fix this is
> to simply make the cell tall enough to fit the text. I'll also try to
> fix handling of glyphs that aren't laid out so it'll behave a bit more
> gracefully when this happens.

The NSTextField used in GWorkspace (BrowserViewer) to edit the icons names
is 14 points tall and the font used is 12 points; and, in Gorm, the Size
Inspector uses text fields of 21 points with a 12 point font.
But both the apps crash when you try to write someting in the field.

NSRangeException:-[GSLayoutManager(glyphs)
effectiveFontForGliphAtIndex:range:] glyph range out of range

Gorm[17852] -[GSLayoutManager(layout)
rangeOfNominallySpacedGlyphsContainingIndex:startLocation:]: can't find
text container for glyph (internal error)

> I'm not really sure what the best way to really fix it is, though. The
> typesetter and layout manager are correct in not laying out any glyphs,
> since the text actually doesn't fit in the cell. On the other hand, the
> current behavior isn't good, since it breaks very easily (if a cell
> isn't tall enough, or if someone uses larger fonts).
>
> One solution might be to add some border case handling to
> GSHorizontalTypesetter to ensure that every text container contains at
> least one line frag rect. (There is already similar code there to ensure
> that every line frag contains at least one glyph. This was necessary to
> solve a somewhat similar problem, but on a line-level and not a
> container-level.) If this works, I'll commit this (until we find a
> better solution, or find that there isn't one).
>
> - Alexander Malmberg
>
>
> _______________________________________________
> Bug-gnustep mailing list
> Bug-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnustep
>