• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Can I use NSTextView this way?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Can I use NSTextView this way?


  • Subject: Can I use NSTextView this way?
  • From: Fritz Anderson <email@hidden>
  • Date: Tue, 30 Sep 2003 17:14:32 -0500

I've come to a baffling pass in my development effort that makes me wonder how useful the Cocoa text facilities can be for tasks that don't strictly cleave to the model of a mini-word-processor. (Likelier, I'm just out of ideas and insight.)

I'm trying to build a terminal emulator. I've got an NSView subclass that puts a vanilla NSTextView at the top, to catch scrollback, and my custom NSTextView subclass at the bottom, which stays the same size as the clip view of the enclosing scroller, and serves as the terminal. The terminal view overrides drawRect: to call the layout manager's drawBackgroundForGlyphRange:atPoint:, and then, piecewise, drawGlyphsForGlyphRange:atPoint:, so I can draw or suppress blinking characters, and double-strike boldfaced characters. The NSTextView drawRect: never gets called.

I have a category on NSTextStorage that ensures the underlying text behaves like an attributed m-by-n matrix of characters.

I use the terminfo-validation tool 'tack' to test my terminal. It seems that well into the string test, which runs a few megabytes through the terminal, NSLayoutManager raises an invalid-range exception as a result of the terminal's -drawRect: sending -drawBackground... . The stack frame for -drawRect: is either damaged or irrecoverable, so I can't learn much from gdb. I do know the view pointer was not nil, and that storage-length and character-to-glyph-range conversions went through before the offending message.

Turning on NSDebugEnabled and NSZombieEnabled had no effect. Tack didn't crash me before I attempted scrollback, so I will make a run with my scrollback mechanism disabled, to isolate that.

However, I'm beginning to fear that the real culprit is that unless an NSTextView is present and used in the "expected" way, the rest of the Cocoa text stack will, sooner or later, collapse in disrepair. I hope this is not the case. The documentation hints at more robust and adventuresome functionality, and I was really pleased at the prospect of getting layout, formatting, selection, and pasteboard copy for very little modification.

The question is, can NSTextView stand such modification, or does Cocoa leave me to do the whole job myself?

-- F
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Re: Getting the User/Owner of another process
  • Next by Date: Re: NSData encoding issues...
  • Previous by thread: Re: NSData encoding issues...
  • Next by thread: Rendezvous and Distributed Objects Help
  • Index(es):
    • Date
    • Thread