Re: Metrics for a NSTextField
Re: Metrics for a NSTextField
- Subject: Re: Metrics for a NSTextField
- From: Eric Gorr <email@hidden>
- Date: Fri, 27 Feb 2009 09:57:15 -0500
Hi Martin,
Martin Wierschin wrote:
>
> Eric Gorr Wrote:
>
> > Martin Wierschin wrote:
>
> Hi Eric,
>
> > > Sizing the editor may not be the window's responsibility- it
may expect
> > > the control to do so. What happens if you resize the NSTextView
and/or
> > > NSTextContainer yourself as needed?
> >
> > This is possible, but the documentation does not say anything about
> > this being necessary.
> >
> > > In fact, you might have to call additional methods before it is
properly
> > > usable, eg: "setUpFieldEditorAttributes:"
> >
> > Well, the documentation for setUpFieldEditorAttributes: says:
> >
> > Sets up the field editor. You never invoke this method directly; by
> > overriding it, however, you can customize the field editor.
> >
> > I have no need to customize it...the default one it provides is
just fine.
>
> 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. The way I read the documentation is that
the forObject parameter provides a control which will configure the
editor.
However, even if I get the field editor, there doesn't appear to be
any guarantee that the NSLayoutManager attached to it will layout the
text in the same way as the NSTextField.
> > What isn't clear how I can get a NSLayoutManager that will layout
the
> > text in the same way as a NSTextField, but perhaps this isn't
possible
> > because NSTextField does custom layout apart from a
NSLayoutManager.
>
> I think you've hit upon the general problem. NSTextField wasn't
designed
> for what you wish it to be. I'd either upgrade to a full NSTextView,
> which always has a dedicated NSLayoutManager attached, or roll your
own
> control whose drawing method is controlled by you.
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:
Custom Hit Testing with thousands of NSTextView's & cursorUpdate:
http://lists.apple.com/archives/cocoa-dev/2009/Feb/msg01910.html
Basically, there is extra stuff going on with a NSTextView which makes
it very inefficient when you need as many as I do. I also am finding
it odd (as seem with the sample application metioned) that Cocoa is
ignoring the fact that I wanted the NSTextView to not be
editable...somehow it is magically changing the editing state of the
field.
I've already been forced to roll my own table view and was hoping that
I would not be forced to roll my own label with editing as well. But,
this does indeed appear to be the path I am being sent down.
Although, perhaps, this may be not so bad as while Apple's provided
controls do not generally allow for customized behavior in areas not
explicitly provided for, they do generally allow one to change how it
looks. 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.
This does seem like it should be unnecessary as I find it hard to
believe that the NSTextField would not be using a NSLayoutManager to
do it's drawing. But, perhaps, either it is old enough or the
NSLayoutManager is new enough that the connection between the two has
not been made.
In any case, here's the bug report related to this again for anyone
who can (and wants to) take a look: rdar://6626911
_______________________________________________
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