FROM : Ricky Sharp
DATE : Sat Jan 05 03:48:28 2008
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_removed>
Instant Interactive(tm) http://www.instantinteractive.com
DATE : Sat Jan 05 03:48:28 2008
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_removed>
Instant Interactive(tm) http://www.instantinteractive.com
| Related mails | Author | Date |
|---|---|---|
| John Stiles | Jan 5, 02:43 | |
| John Stiles | Jan 5, 03:13 | |
| Steve Nygard | Jan 5, 03:14 | |
| John Stiles | Jan 5, 03:20 | |
| Ricky Sharp | Jan 5, 03:48 |






Cocoa mail archive

