• 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
Re: Metrics for a NSTextField
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Metrics for a NSTextField


  • Subject: Re: Metrics for a NSTextField
  • From: Martin Wierschin <email@hidden>
  • Date: Fri, 27 Feb 2009 14:08:17 -0800

Hi Eric,

It may say that, but you're completely bypassing the normal way the field
editor works. I think the documentation is written with the expectation
that the editor will be configured by the control.


Am I? It is unclear that I am indeed completely bypassing the normal way the field editor works.

Yes, you are. The field editor is provided as a shared resource for editing content, not doing on-the-fly layout calculations. There's only one field editor, so if you commandeer it for drawing purposes you're likely interfering with the user's active edit, see:


"The field editor may be in use by some view object, so be sure to properly dissociate it from that object before actually using it yourself"

"The field editor can be shared by any number of objects, and so its state may be constantly changing. Therefore, it shouldn’t be used to display text that demands sophisticated layout (for this you should create a dedicated NSTextView object)."

The way I read the documentation is that the forObject parameter provides a control which will configure the editor.

Consider that the object given to NSWindow is typed as "id". The window has no idea what kind of object that is, nor what layout requirements it has. It's the responsibility of the caller/control to configure the returned editor as needed.


I would like to be able to upgrade to a full NSTextView, but that comes with it's own set of problems which I discussed in the thread:

Using tons of views has always had performance problems. I'm afraid I don't have any advice on that, sorry.


So, what I may be able to do is subclass the NSTextField, write my own drawRect: method which uses a NSLayoutManager that I create myself.

If you just override drawRect you may run into other problems if your text layout differs from that of NSTextField. One example might be when the user first clicks in the field to start an edit. If the text placement differs then the initial placement of the caret (insertion point) may be surprising to the user. Likely there are other annoying gotchas.


You said that using "cellSizeForBounds:" won't serve your purposes, by why not? You said you might need to know how tall 5 lines of text will be- it's not impossible to construct an artificial string/bounds to answer this question.

~Martin

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


References: 
 >Metrics for a NSTextField (From: Eric Gorr <email@hidden>)
 >Re: Metrics for a NSTextField (From: Eric Gorr <email@hidden>)
 >Re: Metrics for a NSTextField (From: Eric Gorr <email@hidden>)
 >Re: Metrics for a NSTextField (From: Eric Gorr <email@hidden>)
 >Re: Metrics for a NSTextField (From: Michael Ash <email@hidden>)
 >Re: Metrics for a NSTextField (From: Eric Gorr <email@hidden>)

  • Prev by Date: Weird "Ignoring bogus layer size" error using Collection View
  • Next by Date: Re: renaming a file with special/reserved characters in name
  • Previous by thread: Re: Metrics for a NSTextField
  • Next by thread: Re: Metrics for a NSTextField
  • Index(es):
    • Date
    • Thread