Bump up the label's content hugging and compression resistance values above the normal/standard values, at least above the values used for "don't particularly care how big they are" views. The default

I would like some help building constraints that adjust a superView to the size of it's subView. Specifically, I have a UILabel embedded in a UIView. The label has fixed width and (since numberOfLines

Hmm, you're right, it worked in a toy project for me. Not counting the window's content view, there is only one level in the view hierarchy. I suspect that the problem is a

You shouldn’t have to do anything else. I just tried it in a standard single-window document template with 3 text fields in the window, and it worked fine without any code. I’ve never tried to use

I have a window with 3 views that I want to be able to switch focus between using the tab or shift-tab keys. Going by the view programming guide, it seems like I shouldn't have to do

I'll be darned, I just assumed it would use UTF-8. Thanks.

Because NSString doesn’t know what text encoding the C string uses, so it just uses the process’s default encoding. This default encoding varies according to the user's locale, and also (last I

Clang has a warning option, -Wcstring-format-directive, that produces a warning "Using %s directive in NSString which is being passed as a formatting argument to the formatting method" on a

Thanks for the ideas! I ended up using a global NSMutableSet.

Very true - as I mentioned it's very old code that hasn’t been revisited in along time. Nevertheless, it’s not deprecated, and has always worked previously. I’ve never found anything in

It’s actually quite an unusual scenario, I finally realized: a. You’re archiving something in a keyed archive without a key. b. You’re archiving using an API that I doubt is used at all very

Ah, makes sense. I wondered about that myself. I tried just leaving it off, but that didn’t work either. Without the source code for the private ‘old array’ class, it’s hard to guess what to

FWIW, 102 is 0x66, or a lower case “f”. Also, I think a “$” at the start of an archive key is an escape character, and so probably shouldn’t be taken literally. However, I don’t know what

Bug Reporter No: 35926492

OK, the bug is reproducible in a very simple test case. Apple have f***ed up for sure here. This writes the simplest possible archive that includes this structure - here’s what it looks like in a

So, this is looking damn strange. So far, it appears is if 10.13.2 has actually broken dearchiving when using this. It may be an intentional breakage, or not. I’ve been through the documentation

Can you find out what @encode(float) is in 10.12 and 10.13.2? Does decoding fail if you use @encode(uint32_t) instead?

Well, 10.13.2 is out, so I now have to solve this issue urgently. Turns out it is in my code (no real surprise) and the issue seems to be with this: [coder decodeArrayOfObjCType:@encode(float)

You could create a persistent reference. If your window controller will have only one instance (such as a non-document app’s main window), you can have a simple static variable in (say) the window

The static analyzer gives me some warnings of possible leaks that I know aren't real leaks, but it makes me think that I may be using a bad design pattern. The situation is that I create an