Skip navigation.
 
mlRe: Glyph Generator & hiding glyphs -> _NSBlockNumberForIndex() errors
FROM : Keith Blount
DATE : Sat Mar 15 13:27:12 2008

Hi,

Sorry to bother you with this again, but it appears that I spoke to soon when I said that this fixes the issue - it doesn't; it still crashes and throws exceptions. And unfortunately I'm now getting no reply from my DTS guy. I put *newGlyphs = NSControlGlyph at line 34 as suggested - you can see the results here:

http://www.literatureandlatte.com/misc/HiddenTextBasicUpdated.zip

If you start typing newlines into the range of text in the right-hand text view that is hidden in the left-hand view, you are right that it no longer crashes at this point. However, when you type newlines into the hidden text, they appear in the left-hand text view too - when they should be hidden, as they are part of the hidden text! Then, if you go back into the left-hand text view and start typing before the hidden text, the whole thing crashes and the following exception gets thrown:

*** layout manager 0x15d6f0 failed to progress beyond index 124 while drawing glyphs.

I don't quite know how I missed this when I first tested with the fix - I guess I was just over-eager for it to work.

I'm not sure if there is anything that can be done, but thank you for your help anyway.

Many thanks and all the best,
Keith

----- Original Message ----
From: Aki Inoue <<email_removed>>
To: Keith Blount <<email_removed>>
Cc: <email_removed>
Sent: Monday, March 10, 2008 11:32:23 PM
Subject: Re: Glyph Generator & hiding glyphs -> _NSBlockNumberForIndex() errors

OK, it appears I made a mistake with the original DTS sample 8-).

NSLayoutManager requires each glyph segment to start with non-null glyphs whereas the sample was replacing all incoming glyphs in the hidden range to NSNullGlyph.


Beginning the range with NSControlGlyph fixes the issue.


Add the following line at HTGlyphGenerator.m:34.


            *newGlyphs = NSControlGlyph;


Aki


On 2008/03/10, at 13:25, Keith Blount wrote:

Hi Aki,

Many thanks for your reply, much appreciated. I completely stripped all my custom drawing code and everything to double-check it wasn't just some bad expectation of glyph-to-character mapping in my own code, but the problem persists. I've uploaded the sample, stripped down project here:

http://www.literatureandlatte.com/misc/HiddenTextTestBasic.zip

All it contains is two text views that share the same text storage, one of which (the left one) uses the custom glyph generator to hide text (given that my real app allows the user to view the same text storage in different panes, it may be that the user has text hidden in one pane but not in the other).

To see the bug in action, all you need to do is build the project, then, in the right-hand text view (where the text isn't hidden), click somewhere between the square brackets (i.e. inside the text that has been hidden in the left-hand text view) and hit return to create a new line twice. The second time you hit return, you will get the following exceptions thrown on the console:

2008-03-10 20:15:21.121 HiddenTextTest[2956:813] Exception raised during background layout:  *** NSRunStorage, _NSBlockNumberForIndex(): index (170) beyond array bounds (163)
2008-03-10 20:15:21.122 HiddenTextTest[2956:813] *** NSRunStorage, _NSBlockNumberForIndex(): index (170) beyond array bounds (163)
2008-03-10 20:15:23.320 HiddenTextTest[2956:813] *** NSRunStorage, _NSBlockNumberForIndex(): index (170) beyond array bounds (163)
2008-03-10 20:15:23.321 HiddenTextTest[2956:813] *** NSRunStorage, _NSBlockNumberForIndex(): index (170) beyond array bounds (163)

After that, you can't type any more - the text view is frozen. You just get more errors along the lines of:

2008-03-10 20:20:16.799 HiddenTextTest[2956:813] Exception raised during background layout:  -[NSLayoutManager _fillLayoutHoleForCharacterRange:desiredNumberOfLines:isSoft:] *** attempted layout while textStorage is editing.  It is not valid to cause the layoutManager to do layout while the textStorage is editing (ie the textStorage has been sent a beginEditing message without a matching endEditing.)

I did find that if I set -setBackgroundLayoutEnabled: to NO, these errors go away, but I suspect that this is really just masking the underlying problem rather than fixing it - and besides, I'd really prefer to have background layout enabled.

Many thanks for taking an interest in this.

All the best,
Keith

----- Original Message ----
From: Aki Inoue <<email_removed>>
To: Keith Blount <<email_removed>>
Cc: <email_removed>
Sent: Monday, March 10, 2008 6:14:05 PM
Subject: Re: Glyph Generator & hiding glyphs -> _NSBlockNumberForIndex() errors

Keith,

I was consulted about the sample from DTS and didn't find any obvious 
problem with it.

It would be great if you could provide further detail (for example, bt 
of the exception raise).

Thanks,

Aki

On 2008/03/08, at 10:41, Keith Blount wrote:

Just to add a little info to my previous message, which was a little 
misleading:a

My custom glyph generator replaces each glyph that is supposed to be 
hidden with NSNullGlyph (it doesn't just insert one NSNullGlyph for 
the lot of them), so I would expect the one-to-one mapping on this 
first pass of glyph generation to be maintained. I'm therefore 
really not sure why I'm getting all of these errors - it seems that 
the presence of a group of null glyphs completely breaks things at 
the typesetting stage (I'm guessing)? Hmm, given that there is so 
little documentation about this sort of thing and most glyph 
generation threads seem to have been unanswered, I don't hold out 
much hope...

In case there is a better way of doing things: I am basically trying 
to implement hidden text, so that text with a given custom attribute 
does not get displayed in the text view. One way I could have done 
this was via a custom text storage subclass that maintained two 
representations of its text - one with the hidden text displayed, 
one with it, um, hidden - but this is no good for what I want, as 
the same text storage can be displayed in two different text views, 
and there is more than one attribute type that can be hidden 
separately.

Hence the custom glyph generator, which isn't working...

Thanks in advance for any help or pointers.
All the best,
Keith


--- ORIGINAL MESSAGE ---

Hi,

I have a custom glyph generator (NSGlyphGenerator subclass) that is 
used to hide glyphs for text with certain attributes. It does this 
by inserting a single NSNullGlyph for a range of glyphs representing 
text with these hidden attributes. (This is basically a hidden text 
toggle.) This all works brilliantly - I can completely hide whole 
ranges of text - but only so long as the text is viewed in a single 
text view.

If I have the same text storage shared between two text views, and 
one view has the text hidden whilst the other doesn't, I get array 
out of bounds errors under the following circumstances: If, in the 
view where no text is hidden, I click in the range of text that IS 
hidden in the other view, and then I hit return a couple of times, I 
get these errors:

Exception raised during background layout:  *** NSRunStorage, 
_NSBlockNumberForIndex(): index (345) beyond array bounds (335)
2008-03-08 10:28:00.042 HiddenTextTest[42350:813] *** NSRunStorage, 
_NSBlockNumberForIndex(): index (345)

Clearly, these errors are caused because my hidden-text view has 
less glyphs in it than the non-hidden-text view, but they both share 
the same text storage. So my question is, how do I fix this? 
Somewhere it seems that I need to tell something else - other than 
my glyph generator - that some text is hidden. The errors seem to 
indicate that I might need to tell my text storage about this... But 
where and how? But then, I can't tell the text storage, because it 
has hidden text in one view but not the other...

The method of hiding text by inserting a null glyph was recommended 
to me by DTS, but there is very little documentation on actually 
achieving something like this, so I'm hoping some text expert here 
will be able to give me some clues. :)

Many thanks in advance and all the best,
Keith




____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________

Cocoa-dev mailing list (<email_removed>)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>

This email sent to <email_removed>






      ____________________________________________________________________________________
Looking for last minute shopping deals? 
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping









      ____________________________________________________________________________________
Looking for last minute shopping deals? 
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Related mailsAuthorDate
No related mails found.