NSTextField doesn't wrap wreliably

Discussion in 'Mac Programming' started by zeppenwolf, Aug 25, 2014.

  1. zeppenwolf macrumors regular

    zeppenwolf

    Joined:
    Nov 17, 2009
    #1
    I have an NSTextField in a window, created by choosing the "Multi-line label / Wrapping Label" object in IB, and it is sized, fonted and otherwise parameterized to support a stringValue being wrapped when it is long enough to do so.

    I want the field to look like this:

    [​IMG]

    and it does look like that... about half of the time. The rest of the time, cocoa shrinks the text, sometimes horrendously, like this:

    [​IMG]

    If you're wondering, that's a point size of 5. It's utterly unreadable and completely absurd.

    WHY is cocoa shrinking my text rather than wrapping it? It is almost as if I had "Uses Single Line Mode" clicked... but I do NOT. I have:

    Text Field Cell / Uses Single Line Mode == false
    Text Field Cell / Layout == Wraps
    Behavior == None
    Cell / Line Break == Word Wrap

    I mentioned that it works half of the time; I mean that I can run the app, open the wind, observe, quit, repeat, over and over... and it sometimes "works" and sometimes doesn't. So on top of everything else, it's the absolute worst thing in the world, it's non-deterministic. I get the same behavior on 0S 10.6 and 10.7, so it must be me somehow.

    What am I missing this time ?
     

    Attached Files:

    • tiny.png
      tiny.png
      File size:
      12.9 KB
      Views:
      1,582
    • wrap.png
      wrap.png
      File size:
      28.1 KB
      Views:
      1,609
  2. Senor Cuete macrumors regular

    Joined:
    Nov 9, 2011
    #2
    Well, "==" means is it equal? and "=" means set the value of the first variable to the value of the second. If you really have it typed as you posted here it definitely won't work. Doesn't the compiler complain about this?
     
  3. zeppenwolf thread starter macrumors regular

    zeppenwolf

    Joined:
    Nov 17, 2009
    #3
    Señor C, I was just describing in "English" or something what settings I had clicked in the settings pane in interface builder. Of course those correspond to values in code... In my actual code, I have these circumstances, in the context of the NSTextField:

    Code:
    [[self cell] usesSingleLineMode] // always 0
    
    [[self cell] wraps] // always 1
    
    [[self cell] lineBreakMode] // always 0, which means 'NSLineBreakByWordWrapping'
    
    [self formatter] // always 0 
    
    [self allowsEditingTextAttributes] // always 0
    
    I don't know what else I can report...? I'm just stumped here, somebody please give me an idea no matter how crazy. I've googled my buns off on this one but it's just not coming up with anything...
     
  4. chown33, Aug 26, 2014
    Last edited: Aug 26, 2014

    chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #4
    Make a simplified test case.

    Start with the default NSTextField in the nib/xib. Build and run it. Does it behave or misbehave?

    If it behaves, change exactly one property from the list of things you listed (singleLineMode, wraps, etc.). Build and run again. Does it behave or misbehave?

    If it behaves, then change another single property.

    If it misbehaves at any point, stop, post the complete project.


    The above is a fundamental debugging strategy: simplify, single changes, systematic, until you're at the same point as the problematic app or until you do something that causes an identifiable misbehavior. The key things are simplicity, single changes, systematic, and stopping as soon as it misbehaves.

    If you get to the point where the test case should be the same as the failing case, but they don't behave identically, then you know that you missed something. That is, something changed that you didn't think of, and didn't treat systematically. To discover what that is, you have to compare the fail case with the test case in every aspect. It would also be a good idea to have more eyes on it, and that means posting the fail case and the non-failing test case, so someone else can compare the two.

    Conversely, if the very first build misbehaves, then post that, along with descriptions of exactly how you made the test case.


    Finally, post the exact OS version and Xcode version you're using. If it's a beta or DP release, identify exactly which one.
     
  5. Partron22 macrumors 68020

    Partron22

    Joined:
    Apr 13, 2011
    Location:
    Yes
    #5
    Have you set the font and point size, and disallowed styled text?
     
  6. briloronmacrumo macrumors 6502

    briloronmacrumo

    Joined:
    Jan 25, 2008
    Location:
    USA
    #6
    Maybe consider NSTextView

    Depending on the goals and needs for this text field, an NSTextView is worth considering. It provides impressive standard functionality with little to no additional code[YMMV]. Set the font in your startup code and go:

    Code:
          [yourNSTextViewObj setFont:[NSFont systemFontOfSize:[NSFont smallSystemFontSize]]]; 
     
  7. Senor Cuete macrumors regular

    Joined:
    Nov 9, 2011
    #7
    [self formatter] appears to do nothing except that it's a pointer to an attribute.

    Same with [self allowsEditingTextAttributes].

    Neither of these seem to assign a value to either attribute. am I mis-understanding this?
     
  8. zeppenwolf thread starter macrumors regular

    zeppenwolf

    Joined:
    Nov 17, 2009
    #8
    OK guys, thank you so much for everyone who helped out.

    To quote Inspector Clouseau, "The case is sol-ved".

    As sometimes happens, the bug turned out to be a "case" of the programmer being as dense as Inspector Clouseau... I would tell you the long story of my following your advice and clues to finally figure it out, but... that would be embarrassing, so let's just say that it's sol-ved.

    It was probably Chown33's recipe which put me over the top, so I am awarding him the Nobel Prize for Second-Party Debugging. It does seem odd that the Nobel Prize Committee put me in charge of this particular prize, but hey-- life is strange.

    But thanks again to everyone.
     
  9. Senor Cuete macrumors regular

    Joined:
    Nov 9, 2011
  10. zeppenwolf thread starter macrumors regular

    zeppenwolf

    Joined:
    Nov 17, 2009
    #10
    Bindings.

    The code which is there, but you can't see it directly while looking at your "normal" code, you have to remember that it's there.

    I didn't remember.
     

Share This Page