Date   

Re: Auto-Layout Question

Steve Christensen
 

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 settings give all views an equal shot to fit together so this prioritizes the label's size. Then set the top, bottom, leading, and trailing edge offsets between the label and its enclosing view.

Assuming nothing else in your overall view hierarchy gets in the way, autolayout will base the enclosing view's size on the label's size.

On Dec 22, 2017, at 10:04 AM, Rick Aurbach <rlaurb@...> wrote:

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 = 0) a height which depends on the label's content. I want to use auto-layout to auto-size the exterior view so that there is a 5 pixel margin around the UILabel.

Suggestions?

Thanks,

Rick Aurbach


Auto-Layout Question

Rick Aurbach
 

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 = 0) a height which depends on the label's content. I want to use auto-layout to auto-size the exterior view so that there is a 5 pixel margin around the UILabel.

Suggestions?

Thanks,

Rick Aurbach


Re: problems with tab key and custom views

James Walker
 

On 12/12/2017 1:59 PM, Quincey Morris wrote:
On Dec 12, 2017, at 13:22 , James Walker <list2@...> wrote:

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 anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

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.

Hmm, you're right, it worked in a toy project for me.

Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil. 

I’ve never tried to use “selectNextKeyView:” but, looking at the documentation, it doesn’t seem to do the obvious thing (use the “nextKeyView” object). Instead, the documentation seems to say that it looks for the “closest” (geometrically, I assume) view in the rest of the next-view loop. This was consistent with my test. When I used “nextKey” to specify a different order for my text fields, the Tab key still jumped between them in geometry order.

Given all that, I’d have to assume that something is causing your window not to be key, or is causing something *else* in the window to be first responder — something at a different level in the view hierarchy. Do your 3 views have subview that can accept first-responder status? If you force one of them to be first responder, what does the Tab key do then?

Finally, don’t forget that windows have an “initialFirstResponder” property that you can use if its default initial choice isn’t what you want.

Not counting the window's content view, there is only one level in the view hierarchy.

I suspect that the problem is a side effect of the (shameful) fact that my app is a Carbon app, so there is some nonstandard handling of events and windows going on.  Anyway, I wrote my own implementations of nextValidKeyView and previousValidKeyView and made all my views use those, and now tab and shift-tab are changing the first responder appropriately, without doing anything special in keyDown:.


Re: problems with tab key and custom views

Quincey Morris
 

On Dec 12, 2017, at 13:22 , James Walker <list2@...> wrote:

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 anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

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.

Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil. 

I’ve never tried to use “selectNextKeyView:” but, looking at the documentation, it doesn’t seem to do the obvious thing (use the “nextKeyView” object). Instead, the documentation seems to say that it looks for the “closest” (geometrically, I assume) view in the rest of the next-view loop. This was consistent with my test. When I used “nextKey” to specify a different order for my text fields, the Tab key still jumped between them in geometry order.

Given all that, I’d have to assume that something is causing your window not to be key, or is causing something *else* in the window to be first responder — something at a different level in the view hierarchy. Do your 3 views have subview that can accept first-responder status? If you force one of them to be first responder, what does the Tab key do then?

Finally, don’t forget that windows have an “initialFirstResponder” property that you can use if its default initial choice isn’t what you want.


problems with tab key and custom views

James Walker
 

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 anything besides set up the nextKeyView loop in the nib and have my views return YES from acceptsFirstResponder, but that's not working.

If I override keyDown: and call interpretKeyEvents:, that doesn't switch to the next view.  So it seems like I must explicitly test for tab and shift-tab events and handle them somehow.


Calling selectNextKeyView: does nothing.  Calling nextValidKeyView returns nil.  Yet, if I call nextKeyView, it returns a non-nil view that is visible and accepts first responder status, so it seems like nextValidKeyView is not working as documented.  If I find the next key view the hard way and make it first responder, it does become first responder, but it seems like it shouldn't be so hard.


Re: warning about %s in format string

James Walker
 

On 12/8/2017 3:39 PM, Jens Alfke wrote:
On Dec 8, 2017, at 9:44 AM, James Walker <list2@...> wrote:

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 line like:

NSString* x = [NSString stringWithFormat: @"File %s", __FILE__];

Can someone please explain to me why this is something worth avoiding, or worth warning about?  I tried Googling, couldn't find anything.

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 checked) even if that locale is English (or most European languages) the encoding is not something useful like UTF-8 but rather the incredibly obsolete MacRoman.

The tl;dr is that if you format a non-ASCII C string with “%s” it's probably going to get mangled. In your example above, this would occur if the source file or any parent directory had a non-ASCII name.

(This is the same reason why -[NSString initWithCString:] is deprecated.)

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


Re: warning about %s in format string

 



On Dec 8, 2017, at 9:44 AM, James Walker <list2@...> wrote:

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 line like:

NSString* x = [NSString stringWithFormat: @"File %s", __FILE__];

Can someone please explain to me why this is something worth avoiding, or worth warning about?  I tried Googling, couldn't find anything.

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 checked) even if that locale is English (or most European languages) the encoding is not something useful like UTF-8 but rather the incredibly obsolete MacRoman.

The tl;dr is that if you format a non-ASCII C string with “%s” it's probably going to get mangled. In your example above, this would occur if the source file or any parent directory had a non-ASCII name.

(This is the same reason why -[NSString initWithCString:] is deprecated.)

—Jens


warning about %s in format string

James Walker
 

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 line like:

NSString* x = [NSString stringWithFormat: @"File %s", __FILE__];

Can someone please explain to me why this is something worth avoiding, or worth warning about?  I tried Googling, couldn't find anything.


Re: potential leak warnings from static analyzer on window controllers

James Walker
 

On 12/7/2017 11:29 AM, Quincey Morris wrote:
On Dec 7, 2017, at 09:32 , James Walker <list2@...> wrote:

What should I be doing differently?

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 controller class’s implementation file. If there are multiple window controllers, you can add the references to a global array in (say) the app delegate (and do a release after adding, to keep the retain count balanced).

Then, when the window closes, you will release and nil the static variable, or remove the reference from the array, rather than doing the [self release].

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


Re: Launching apps on 10.13.2

Graham Cox
 

On 8 Dec 2017, at 4:52 pm, Quincey Morris <quinceymorris@...> wrote:

On Dec 7, 2017, at 21:44 , Graham Cox <graham@...> wrote:

unreadable archives with no workaround is quite serious
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 often. (Also, the non-array version of the …ObjCType API is deprecated.)
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 documentation that suggests it’s not something that should be used. I’m certainly willing to update my code to use something more robust in future, but that still leaves the problem of reading the existing archives.

—Graham


Re: Launching apps on 10.13.2

Quincey Morris
 

On Dec 7, 2017, at 21:44 , Graham Cox <graham@...> wrote:

unreadable archives with no workaround is quite serious

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 often. (Also, the non-array version of the …ObjCType API is deprecated.)


Re: Launching apps on 10.13.2

Graham Cox
 

On 8 Dec 2017, at 4:05 pm, Quincey Morris <quinceymorris@...> wrote:

On Dec 7, 2017, at 19:06 , Graham Cox <graham@...> wrote:

The code in the test app is this:
FWIW, 102 is 0x66, or a lower case “f”.
Ah, makes sense.


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 key you’d need to ask for instead.
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 try.




On to the code…

The first few times I tried this, I thought I got inconsistent results, but maybe I just did something wrong. The last several times I tried, I got the same exception as you, but only with the “float” type. All the other types I tried worked.

I think it must have fallen through the one crack in the testing. I’d hate to think they didn’t test it at all… ;-)


One odd thing I noted. If I encoded the array as anything other than float elements (e.g. specifying “@encode(double)” or “@encode(short)”), and decoded with “@encode(float)”, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray decodeArrayOfObjCType:count:at:]: type ('f') or count (6) does not match stored type and count ('d', 6)
but if I encoded the array as “@encode(float)” and decoded it as anything else, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray initWithCoder:]: unable to decode element in array of size (4) and count (6)
It’s very odd.
Indeed. We’ve raised a DTS support incident so that it gets looked at quickly - I would imagine if the bug really is there, we can’t be the only ones screaming about this - unreadable archives with no workaround is quite serious.

—Graham


Re: Launching apps on 10.13.2

Quincey Morris
 

On Dec 7, 2017, at 19:06 , Graham Cox <graham@...> wrote:

The code in the test app is this:

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 key you’d need to ask for instead.

On to the code…

The first few times I tried this, I thought I got inconsistent results, but maybe I just did something wrong. The last several times I tried, I got the same exception as you, but only with the “float” type. All the other types I tried worked.

One odd thing I noted. If I encoded the array as anything other than float elements (e.g. specifying “@encode(double)” or “@encode(short)”), and decoded with “@encode(float)”, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray decodeArrayOfObjCType:count:at:]: type ('f') or count (6) does not match stored type and count ('d', 6)

but if I encoded the array as “@encode(float)” and decoded it as anything else, I got this exception message:

*** -[_NSKeyedCoderOldStyleArray initWithCoder:]: unable to decode element in array of size (4) and count (6)

It’s very odd.



Re: Launching apps on 10.13.2

Graham Cox
 

Bug Reporter No: 35926492

On 8 Dec 2017, at 2:06 pm, Graham Cox <graham@...> wrote:

Submitting a bug report now. The annoying thing is that I can’t see any workaround. This is a killer for our users right now. Grrrr…..


Re: Launching apps on 10.13.2

Graham Cox
 

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 plist editor:




Running this on 10.13.2 throws an exception. Earlier system versions are fine.

The code in the test app is this:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// create an archive using -encodeArrayOfObjCType:count:at: with 32-bit floats

NSString* path = [@"~/Desktop/testArchive.plist" stringByExpandingTildeInPath];

float testValues[] = {1.0, 2.0, 3.5, 4.6, 3.1415926, 0.0};

NSMutableData* testArchive = [NSMutableData data];

NSKeyedArchiver* archiver = [[NSKeyedArchiver alloc] initForWritingWithMutableData:testArchive];

[archiver encodeArrayOfObjCType:@encode(float) count:6 at:testValues];
[archiver finishEncoding];

[testArchive writeToFile:path atomically:YES];

// now read it back in and see if it can be dearchived - in 10.13.2, this will throw an exception.


NSData* readArchive = [NSData dataWithContentsOfFile:path];

NSKeyedUnarchiver* unarchiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:readArchive];

float readValues[6];

[unarchiver decodeArrayOfObjCType:@encode(float) count:6 at:readValues];
[unarchiver finishDecoding];

for( int i = 0; i < 6; ++i )
NSAssert( readValues[i] == testValues[i], @"dearchived data does not match values archived");

}

Submitting a bug report now. The annoying thing is that I can’t see any workaround. This is a killer for our users right now. Grrrr…..

On 8 Dec 2017, at 1:42 pm, Graham Cox <graham@...> wrote:

I’m going to create a simple test case that shows the problem in isolation (if it does), and submit it as a bug. I’m thinking that this particular feature of archiving is not used much, Apple have broken it, and it wasn’t picked up in testing. Again, I’m reluctant to draw this conclusion, but that’s how it looks right now.


Re: Launching apps on 10.13.2

Graham Cox
 

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 and it seems is though [-NSKeyedArchiver encodeArrayOfObjCType:@encode(float) …] is perfectly legal. @encode(float) basically returns the C string “f”. It looks as if 10.13 added a more secure mechanism for encoding and decoding arbitrary types - I’m wondering if somehow accommodating this new API has broken the old one.

(DISCLAIMER: I’m reluctant to point the finger at OS code when things don’t work for obvious reasons, but hear me out!)

This is a fragment of the archive that is written (complete archive attached):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>$0</key>
<real>4</real>
<key>$1</key>
<real>1</real>
<key>$2</key>
<real>1</real>
<key>$3</key>
<real>1</real>
<key>$class</key>
<dict>
<key>CF$UID</key>
<integer>11</integer>
</dict>
<key>NS.count</key>
<integer>4</integer>
<key>NS.size</key>
<integer>4</integer>
<key>NS.type</key>
<integer>102</integer>
</dict>
</plist>


This is a dictionary embedded in the archive corresponding to the use of -encodeArrayOfObjCType:

In this case I’ve written 4 float values, as can be seen in the corresponding NS.count entry. The values of the elements of the array are keyed using $0..$3. (the corresponding values are 4.0, 1.0, 1.0, 1.0)

I’m not sure how NS.type works, but its value is always 102 for these float arrays.

When NSKeyedDearchiver is asked to dearchive this array, internally it makes an object with the class _NSKeyedCoderOldStyleArray, and calls -initWithCoder: on it. That method throws the exception "*** -[_NSKeyedCoderOldStyleArray initWithCoder:]: unable to decode element in array of size (4) and count (2)” noted earlier. To try and figure out what’s going on, I’ve created a class of my own which I can substitute for this class. My class gets created and called instead as expected, and I can ask the decoder for NS.count, NS.type, NS.size, and I get back the values from the archive as expected.

But when I ask for the value of the key “$0”, it doesn’t exist. Nor do any of the others. Presumably this is what _NSKeyedCoderOldStyleArray is discovering as well, and throws the exception.

At this point it’s unclear what the further problem is - is NSKeyedArchiver disallowing the key, or is it really the case that the key doesn’t exist - I don’t know. Peeking at what data members of NSKeyedUnarchiver I can, I can’t see anything useful.

I’m going to create a simple test case that shows the problem in isolation (if it does), and submit it as a bug. I’m thinking that this particular feature of archiving is not used much, Apple have broken it, and it wasn’t picked up in testing. Again, I’m reluctant to draw this conclusion, but that’s how it looks right now.

It would be useful if someone else could check this out to confirm or disprove it though.

—Graham

On 8 Dec 2017, at 1:11 pm, Quincey Morris <quinceymorris@...> wrote:

On Dec 7, 2017, at 16:34 , Graham Cox <graham@...> wrote:

It makes me wonder if @encode(float) is actually legal, or perhaps I’ve just been getting away with it for years?
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?


Re: Launching apps on 10.13.2

Quincey Morris
 

On Dec 7, 2017, at 16:34 , Graham Cox <graham@...> wrote:

It makes me wonder if @encode(float) is actually legal, or perhaps I’ve just been getting away with it for years?

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?


Re: Launching apps on 10.13.2

Graham Cox
 

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) count:m_count at:tempPattern];

Invoking this causes an internal exception : "*** -[_NSKeyedCoderOldStyleArray initWithCoder:]: unable to decode element in array of size (4) and count (2)”

This is very old code that has always worked up until now. I can certainly rewrite this code to use something more robust - but the problem is a lot of existing data that has written an archive this way can’t be read, and that is a problem. I need a way to read it, even if it’s only to convert it to another form.

The corresponding archiving step is:

float tempPattern[8];
[coder encodeArrayOfObjCType:@encode(float) count:[self count] at:tempPattern];



It makes me wonder if @encode(float) is actually legal, or perhaps I’ve just been getting away with it for years?

Anyway, if anyone can see a way I could read the contents of such an archive, I’d be very grateful.

—Graham


Re: potential leak warnings from static analyzer on window controllers

Quincey Morris
 

On Dec 7, 2017, at 09:32 , James Walker <list2@...> wrote:

What should I be doing differently?

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 controller class’s implementation file. If there are multiple window controllers, you can add the references to a global array in (say) the app delegate (and do a release after adding, to keep the retain count balanced).

Then, when the window closes, you will release and nil the static variable, or remove the reference from the array, rather than doing the [self release].


potential leak warnings from static analyzer on window controllers

James Walker
 

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 instance of a subclass of NSWindowController, and when the window closes, the controller releases itself.  The static analyzer reports a possible leak at the point of creation.  This window is not associated with an NSDocument, and it is non-ARC code.  What should I be doing differently?

981 - 1000 of 1457