Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

zeppenwolf

macrumors regular
Original poster
Nov 17, 2009
129
3
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:

attachment.php


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

attachment.php


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 ?
 

Attachments

  • tiny.png
    tiny.png
    12.9 KB · Views: 2,306
  • wrap.png
    wrap.png
    28.1 KB · Views: 2,466
I have:

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

What am I missing this time ?

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?
 
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...
 
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.
 
Last edited:
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]]];
 
...
[self formatter] // always 0

[self allowsEditingTextAttributes] // always 0
[/CODE]
...

[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?
 
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.
 
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.