• 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: Editable NSTextField and layout
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Editable NSTextField and layout


  • Subject: Re: Editable NSTextField and layout
  • From: Ricky Sharp <email@hidden>
  • Date: Fri, 4 Jan 2008 20:48:28 -0600


On Jan 4, 2008, at 7:43 PM, John Stiles wrote:

I've found what appears to be a bug in NSTextField but I'm not sure how exactly to classify it or work around it.
You can reproduce it entirely via Interface Builder (though I originally found it in code).
Steps:
- Open IB3 and create a Cocoa window
- Drag in an editable NSTextField
- In the Inspector, view its Attributes
- Change Layout from "Scrolls" to "Wraps," and then back to "Scrolls"
- Test drive the interface and try typing in more text than the edit field can contain


You'll find that once the edit field fills up, the insertion point pins itself to the right edge of the edit field but the text never scrolls. It appears that your input is being discarded, but it's actually being invisibly accepted; the only way to see it is to copy- and-paste it out or to delete the beginning of the string so that the characters scroll back into view.

What's going on here? This can't be right.

Confirmed with IB3 on 10.5.1. That's really a strange one. I think going from Scrolls to Wraps is setting up some internal state. And, when going back to Scrolls, some part of that state is left-over. It looks like it's still kinda in wrap mode since the first character that would trigger a wrap is, as you say, not drawn. Perhaps it is being drawn, but on the second line (which is now hidden since no auto scrolling vertical-wise is occurring.


FYI: If I duplicate (copy/paste) the bad edit field, its copy will also be in this bad state. Saving the xib, closing IB and re-opening the xib yields the same outcome. Thus, even the bad state is being written down via the object's encodeWithCoder call.

I've only tested in Leopard but I'm thinking about verifying in Tiger and then filing a Radar.

For the curious, I got similar behavior in my code by calling [[myTextField cell] setWraps:NO] (on a text field created programmatically, via [[NSTextField alloc] initWithFrame:]).


Definitely file a bug. My guess is this is most likely a bug in the actually framework and nothing to do with IB.

___________________________________________________________
Ricky A. Sharp         mailto:email@hidden
Instant Interactive(tm)   http://www.instantinteractive.com

_______________________________________________

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: 
 >Editable NSTextField and layout (From: John Stiles <email@hidden>)

  • Prev by Date: Re: Select MenuItem
  • Next by Date: Re: Window close button issue in Leopard
  • Previous by thread: Re: Editable NSTextField and layout
  • Next by thread: Select MenuItem
  • Index(es):
    • Date
    • Thread