Editable NSTextField and layout

  • 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.

    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:]).
  • Okay, F-Script Anywhere to the rescue. Apparently this sequence of
    events causes the "scrollable" property of the NSTextFieldCell to become
    NO (it starts as YES if you create it in IB). Everything else was the
    same. I guess I'll file a radar since there's no reason that this should
    happen.

    Interestingly, a programmatically created NSTextField's cell also seems
    to have its scrollable property set to NO by default (and its line-break
    mode is "break by word-wrapping" instead of IB's "break by clipping"). I
    guess this is normal since these settings probably make the most sense
    for a non-editable text field.

    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.
    >
    > 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:]).
  • On 4-Jan-2008, at 18:43 , 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.

    There are two separate NSCell flags, isScrollable and wraps.  When you
    set one to YES, the other is changed to NO. I'm guessing IB is only
    setting the wraps flag from the popup, so both flags end up as NO.
    (IB on Tiger just sets the other flag, so you can't make the cell
    wrap.)  It should set the appropriate flag to YES to make it work.

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

    I filed a bug report about this yesterday.

    --
    Steve
  • Heh, I came to the same conclusion and filed a radar as well. Good to
    see that I'm not the only one!

    Steve Nygard wrote:
    >
    > On 4-Jan-2008, at 18:43 , 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.
    >
    > There are two separate NSCell flags, isScrollable and wraps.  When you
    > set one to YES, the other is changed to NO. I'm guessing IB is only
    > setting the wraps flag from the popup, so both flags end up as NO.
    > (IB on Tiger just sets the other flag, so you can't make the cell
    > wrap.)  It should set the appropriate flag to YES to make it work.
    >
    >> I've only tested in Leopard but I'm thinking about verifying in Tiger
    >> and then filing a Radar.
    >
    > I filed a bug report about this yesterday.
    >
    > --
    > Steve
  • 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:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today