camera shutter sound is not eared the first time.
Hi all.I've implemented an app using the camera (UIImagePickerController). After I've updated my system to iOS 8.1.1 on iPhone 5S, the behaviour of my app is changed. When I take the first picture the sound of the camera shutter is not played. After the first one, the shutter sound is played normally for the next clicks on the shutter button. I'm using Xcode 6.1 Any Idea? Luca. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Weird crash in FSRefCreate while saving NSDocument
Hello, I have a user who keeps crashing our app by saving his NSDocument (file wrapper based). I can't make any sense of it and he's the only one who runs into this, apparently. I'm attaching the call stack of the crash in the hope that someone on the list recognizes it. Any ideas what might be going on? Regards Markus Crashed Thread:5 Dispatch queue: com.apple.root.default-qos Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0048 VM Regions Near 0x48: --> __TEXT 00010d12f000-00010d539000 [ 4136K] r-x/rwx SM=COW /Applications/My.app/Contents/MacOS/My Thread 5 Crashed:: Dispatch queue: com.apple.root.default-qos 0 com.apple.CoreServices.CarbonCore 0x7fff8a120b20 FSRefCreate + 56 1 com.apple.CoreServices.CarbonCore 0x7fff8a11f174 FSPathMakeRefInternal(unsigned char const*, unsigned int, unsigned int, FSRef*, unsigned char*) + 247 2 com.apple.CoreFoundation0x7fff940b3984 _CFGetFSRefFromURL + 228 3 com.apple.CoreFoundation0x7fff940b3885 CFURLGetFSRef + 37 4 com.apple.LaunchServices 0x7fff8b713337 ___LSGetStrongBindingForRef_block_invoke + 61 5 com.apple.LaunchServices0x7fff8b74e922 _LSShimFSRef + 68 6 com.apple.LaunchServices0x7fff8b7132f4 _LSGetStrongBindingForRef + 68 7 com.apple.CoreServicesInternal 0x7fff90f9c054 _URLReplaceObject + 7423 8 com.apple.CoreFoundation0x7fff9417c382 _CFURLReplaceObject + 114 9 com.apple.Foundation 0x7fff90604999 -[NSFileManager replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:] + 248 10 com.apple.Foundation 0x7fff90728466 +[NSFileWrapper(NSInternalForAppKit) _finishWritingToURL:byTakingContentsFromItemAtURL:addingAttributes:usingTemporaryDirectoryAtURL:backupFileName:error:] + 114 11 com.apple.AppKit 0x7fff95fda777 -[NSDocument _finishWritingToURL:byTakingContentsFromItemAtURL:replacingOriginalItemAtURL:addingAttributes:usingTemporaryDirectoryAtURL:backupFileName:error:] + 155 12 com.apple.AppKit 0x7fff95fdc987 __86-[NSDocument _writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:]_block_invoke + 819 13 com.apple.AppKit 0x7fff95fdc361 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:] + 2120 14 com.apple.AppKit 0x7fff95fdcb93 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:error:] + 28 15 com.apple.AppKit 0x7fff95fdcd01 -[NSDocument writeSafelyToURL:ofType:forSaveOperation:error:] + 357 16 com.apple.AppKit 0x7fff95fe9fc5 __66-[NSDocument saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke_22307 + 240 17 libdispatch.dylib 0x7fff8e15d323 _dispatch_call_block_and_release + 12 18 libdispatch.dylib 0x7fff8e158c13 _dispatch_client_callout + 8 19 libdispatch.dylib 0x7fff8e15b88f _dispatch_root_queue_drain + 935 20 libdispatch.dylib 0x7fff8e169fe4 _dispatch_worker_thread3 + 91 21 libsystem_pthread.dylib 0x7fff895936cb _pthread_wqthread + 729 22 libsystem_pthread.dylib 0x7fff895914a1 start_wqthread + 13 -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSStackView layout issues
> On 23 Nov 2014, at 16:48, SevenBits wrote:
>
> Hello Cocoaphiles, ;)
>
> I've just started experimenting with NSStackView, and I'm having a very
> interesting problem which I can't solve. I've scoured the auto layout guides
> on Apple's website as well as the NSStackViewdocumentation, and can't seem to
> find anything.
>
> From what I understand, the intrinsic content size should prohibit the view
> from getting shrunk this small. I'm not too familiar with NSStackView, so any
> help would be appreciated.
>
I think you will find that NSScrollView -intrinsicContentSize will return
{NSViewNoIntrinsicMetric, NSViewNoIntrinsicMetric}.
i.e: a scroll view doesn’t report an intrinsic content size.
NSStackView calls -fittingSize to determine the size for its subviews.
If you add a subview to a vertical NSStackView without a fully constrained
height it collapses to zero - ish.
Often, if you ask XCode to add contains to your view it will not fully
constrain the height of the view.
This cases them to misbehave in an NSStackView.
So the point is add some constraints!
NSStackView is supremely useful once you get your head around the constraint
basics.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSLog(@"- intrinsicContentSize : %@",
NSStringFromSize(self.textScrollView1.intrinsicContentSize));
NSLog(@"- fitting size: %@",
NSStringFromSize(self.textScrollView1.fittingSize));
self.textScrollView1.translatesAutoresizingMaskIntoConstraints = NO;
self.textScrollView2.translatesAutoresizingMaskIntoConstraints = NO;
self.stackView.alignment = NSLayoutAttributeWidth;
[self.stackView addView:self.textScrollView1
inGravity:NSStackViewGravityTop];
[self.stackView addView:self.textScrollView2
inGravity:NSStackViewGravityTop];
NSDictionary *views = NSDictionaryOfVariableBindings(_textScrollView1,
_textScrollView2);
[self.stackView addConstraints:[NSLayoutConstraint
constraintsWithVisualFormat:@"V:[_textScrollView1(==_textScrollView2)]"
options:0
metrics:nil
views:views]];
}
I use the following with view -hidden bindings to manipulate complex view stacks
https://github.com/mugginsoft/TSStackView
Jonathan
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: codesign v2 problem on 10.8.5 and earlier
Hi, it seems the issue is related to a 3rd party framework I am using. Tamas > On 24 Nov 2014, at 08:32, Tamas Nagy wrote: > > Hi, > > switched to codesign v2 to match the new requirements on 10.9.5 and 10.10. > The sign works well on 10.9.5 and later, but on 10.8.5 (with the latest > security update installed) the verify process (codesign —verify —deep > —verbose=2 …) reports “bundle format unrecognized, invalid or unsuitable”, > which results Gatekeeper reporting the “.app has been damaged, you should > move it to the Trash”. If I don’t miss something, codesign v2 should be > compatible with 10.8.5 and earlier. > > Anyone ran into the same issue? What did I miss? > > Thank you! > > Tamas ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
On Nov 23, 2014, at 11:15 PM, Jens Alfke wrote: > (I spent four years of my life immersed in RSS feed parsing, and acquired a > solid contempt for the ability of the average web developer to construct a > valid feed. You would not believe how many messed-up feeds there are in the > real world.) > > —Jens XML feeds, you say? On Friday, we ran into an issue where our iOS app produced an obscure error when our app was reactivated but our Android app didn't report the same issue. On iOS, the error that was reported was "control character at position 1072", or something to that effect. We were parsing results from a JSON URL, not an XML feed. Well, our server guys put up a JSON file that we simply had to fetch from the server, but didn't bother to run it through JSONLint. What happened was that one of out text strings within the JSON was so long, it was scrolling off the screen. Obviously, their editor didn't have this advanced feature called line wrap and the person typing in the JSON pressed enter in the middle of the line so he could see the whole string. The Android parser doesn't seem to care about return/enter characters, but the iOS JSON parser sure does. Fun times when your web guys hand enter the JSON and don't bother to validate it. And this is in a product that was supposed to ship on last Friday. Misery obviously loves company. Cheers, - Alex ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crash in FSRefCreate while saving NSDocument
On Nov 24, 2014, at 3:03 AM, Markus Spoettl wrote: > > I'm attaching the call stack of the crash in the hope that someone on the > list recognizes it. Any ideas what might be going on? Is this 10.10? And the libs are still using FSRef underneath their implementations??? Hoo boy. I've seen 10.10 get into a state where FSPathMakeRef will report fnfErr when the file is sitting right there, with correct permissions. In fact, you can stat the file without error, then immediately call FSPathMakeRef with the same path, and get an error. (Full path, only a-z & 0-9 in any of the names...) I've also seen the case of: 1) get an FSRef, 2) create a new file elsewhere, 3) FSRefMakePath on the FSRef now fails. Unfortunately I haven't been able to figure out anything about the circumstances except that PID 1 was going crazy at the time, and a reboot fixed everything. I simply eliminated all my FSRef code, which I had intended to do RSN anyway, and replaced with plain POSIX stuff. But if 10.10 is using FSRefs in the implementation of Cocoa, I guess other people are going to trip over the bugs... So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
> On Nov 24, 2014, at 5:15 AM, Alex Zavatone wrote: > > The Android parser doesn't seem to care about return/enter characters, but > the iOS JSON parser sure does. The grammar at json.org (in the right sidebar on the home page) explicitly says strings can't contain control characters. I've had other parsers complain about them too, not just Apple's, so this looks like an Android bug. But then, JSON ≠ XML, so this is off-topic for this thread... —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Weird crash in FSRefCreate while saving NSDocument
On 24/11/14 14:54, Scott Ribe wrote: On Nov 24, 2014, at 3:03 AM, Markus Spoettl wrote: I'm attaching the call stack of the crash in the hope that someone on the list recognizes it. Any ideas what might be going on? Is this 10.10? And the libs are still using FSRef underneath their implementations??? Sorry forgot to mention it, yes, this is on 10.10.1. Hoo boy. I've seen 10.10 get into a state where FSPathMakeRef will report fnfErr when the file is sitting right there, with correct permissions. In fact, you can stat the file without error, then immediately call FSPathMakeRef with the same path, and get an error. (Full path, only a-z & 0-9 in any of the names...) I've also seen the case of: 1) get an FSRef, 2) create a new file elsewhere, 3) FSRefMakePath on the FSRef now fails. Unfortunately I haven't been able to figure out anything about the circumstances except that PID 1 was going crazy at the time, and a reboot fixed everything. I simply eliminated all my FSRef code, which I had intended to do RSN anyway, and replaced with plain POSIX stuff. But if 10.10 is using FSRefs in the implementation of Cocoa, I guess other people are going to trip over the bugs... So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. OK, thanks, it's a start! I'll try to get my user to try this. I'll report back if that changes anything. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
Verstuurd vanaf mijn iPhone
> Op 24 nov. 2014 om 04:13 heeft Keary Suska het
> volgende geschreven:
>
>> On Nov 23, 2014, at 11:06 AM, Diederik Meijer | Ten Horses
>> wrote:
>>
>> I am having trouble getting useful data from this url on some, but not all,
>> iOS devices:https://www.taxpublications.deloitte.co.uk/tis/dtp.nsf/pub1.xml
>>
>> The feed has this opening tag:
>>
>> When I just pull in the feed’s contents using a NSURLConnection, it will
>> show up on some, but not all, devices.
>>
>> When I try to log the response data, by creating a string that I init with
>> the downloaded data and NSUTF8StringEncoding, the log will show a null
>> string. So putting the downloaded data into a string using UTF8 doesn’t work.
>>
>> NSString *dataString = [[NSString alloc] initWithData:self.dataContainer
>> encoding:NSUTF8StringEncoding];
>
> The above code is wrong in your case. The second parameter must be the
> encoding that the characters are currently in, not the encoding you want
> NSString is--at least outwardly--encoding-agnostic. It doesn't care what you
> feed into it, it will always spit out UTF8 unless you specify otherwise.
Agreed
>
>> Still, in that case, some devices will show the parsed feed, some won’t.
>
> Separating the erros in your debugging attempts vs what might actually be
> happening is more useful at the moment.
Agreed, but I have no clear errors
>
>> I tried converting the data into NSISOLatin1 and then putting it back into
>> NSData using UTF8, as below, but that doesn’t help.
>
> This would be entirely pointless, as the XML parser shouldn't care what
> character encoding is used, as long as it is declared. UTF8 is magical for
> the parser.
>
>> -(void)connectionDidFinishLoading:(NSURLConnection *)connection {
>> NSString *dataString = [[NSString alloc] initWithData:self.dataContainer
>> encoding:NSISOLatin1StringEncoding];
>
> This line is the proper way to convert the data into a string. You can then
> NSLog() with impunity. I would also include the data length, just to make
> sure that a nil result is not due to empty or nil data.
>
Will try this, thanks
>> [self setDataContainer:[[dataString
>> dataUsingEncoding:NSUTF8StringEncoding] mutableCopy]];
>> self.xmlItems = [NSMutableArray array];
>> NSXMLParser *parser = [[NSXMLParser alloc]
>> initWithData:self.dataContainer];
>> [parser setDelegate:self];
>> [parser parse];
>> }
>>
>>
>> I validated the feed’s XML and got no errors..
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
>
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
Verstuurd vanaf mijn iPhone > Op 24 nov. 2014 om 05:15 heeft Jens Alfke het volgende > geschreven: > > >> On Nov 23, 2014, at 1:06 PM, Diederik Meijer | Ten Horses >> wrote: >> >> When I just pull in the feed’s contents using a NSURLConnection, it will >> show up on some, but not all, devices. > > What does "show up" mean in this case? Is there an error? If so, what is it? It means that sometimes the feed is parsed into an NSArray of NSDictionairies that is datasource to a UITableView which loads fine, while in other cases no data gets shown in the TVC, it stays empty I get no errors, but no results from the parser either. I haven't tested against didStartElement, because it seems clear that no data goes into the parser. NSJSONSeriliazation would throw a 'data is nil' error if it were JSON, NSXMLParser doesn't seem to do that Can this be a special characters, "you should escape some of them" issue? > >> When I try to log the response data, by creating a string that I init with >> the downloaded data and NSUTF8StringEncoding, the log will show a null >> string. So putting the downloaded data into a string using UTF8 doesn’t work. > > UTF-8 is a completely different encoding. > >> I validated the feed’s XML and got no errors.. > > It's valid XML, but it's got some problems as an RSS feed; take a look at > > http://feedvalidator.org/check.cgi?url=https%3A%2F%2Fwww.taxpublications.deloitte.co.uk%2Ftis%2Fdtp.nsf%2Fpub1.xml > These are mostly minor, like nonstandard extra elements, but it's also got > problems with its date formatting, and also the server reports the > Content-Type is ASCII while the XML says it's ISO-8859-1. > > If NSXMLParser is having trouble with the encoding, one problem I've seen > before is documents that claim to be ISO-8859-1 while actually being > WinLatin, which is a superset with extra characters defined. (The Cocoa > encoding name for this is NSWindowsCP1252StringEncoding, IIRC.) > Thanks, will try that > (I spent four years of my life immersed in RSS feed parsing, and acquired a > solid contempt for the ability of the average web developer to construct a > valid feed. You would not believe how many messed-up feeds there are in the > real world.) > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
> On Nov 24, 2014, at 9:30 AM, Diederik Meijer | Ten Horses > wrote: > > I get no errors, but no results from the parser either. I haven't tested > against didStartElement, because it seems clear that no data goes into the > parser. Did you implement these delegate methods: - (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError; - (void)parser:(NSXMLParser *)parser validationErrorOccurred:(NSError *)validationError; ? I'm pretty sure that NSXMLParser wouldn't fail without returning any sort of error. If it does, you should file a bug report with Apple once you have a reproducible case. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble getting ISO-8859-1 encoded feed to parse and display
Op 24 Nov 2014, om 19:01 heeft Jens Alfke het volgende
geschreven:
>
>> On Nov 24, 2014, at 9:30 AM, Diederik Meijer | Ten Horses
>> wrote:
>>
>> I get no errors, but no results from the parser either. I haven't tested
>> against didStartElement, because it seems clear that no data goes into the
>> parser.
>
> Did you implement these delegate methods:
> - (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError;
> - (void)parser:(NSXMLParser *)parser validationErrorOccurred:(NSError
> *)validationError;
> ?
I have now (see below), doesn’t show me anything in the simulator, will test on
one of the erring devices tomorrow, by the way, both of the following lines log
the data content out just fine:
NSString *dataString = [[NSString alloc] initWithData:self.dataContainer
encoding:NSISOLatin1StringEncoding];
NSString *dataString = [[NSString alloc] initWithData:self.dataContainer
encoding:NSWindowsCP1252StringEncoding];
>
> I'm pretty sure that NSXMLParser wouldn't fail without returning any sort of
> error. If it does, you should file a bug report with Apple once you have a
> reproducible case.
>
> —Jens
>
- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError {
UIAlertView *av = [[UIAlertView alloc] initWithTitle:@"PARSE ERROR IN
CHANNEL" message:[parseError localizedDescription] delegate:nil
cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
[av show];
NSLog(@"ERROR IN CHANNEL: %@", [parseError localizedDescription]);
}
- (void)parser:(NSXMLParser *)parser validationErrorOccurred:(NSError
*)validationError {
UIAlertView *av = [[UIAlertView alloc] initWithTitle:@"VALIDATION ERROR IN
CHANNEL" message:[validationError localizedDescription] delegate:nil
cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
[av show];
NSLog(@"ERROR IN CHANNEL: %@", [validationError localizedDescription]);
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Unexpected extra "change" notification in 10.10
> On 24 Nov 2014, at 12:55 pm, Jerry Krinock wrote: > > To clarify the issue: -updateChangeCount: is called, as expected, when you > dirty the document. It is called again when you save the document, > apparently just after you save the document, because > >> This causes the document to be flagged as dirty, prompting the "Save >> changes?" dialog when it's closed (if that is enabled). > > > It is the second call to -updateChangeCount:, which occurs during/after the > save, that is the issue. Have I understood correctly? Yes. The -updateChangeCount: mechanism is working normally for genuine changes, which are sent as the result of a notification from the undo manager. I'm getting an extra one after the save completes, but only for the first save, and only if it creates a new file rather than overwriting an existing one. >> It doesn't seem as if I'm doing anything wrong as we're not seeing this >> except on 10.10 > > See if it’s putting an action on the undo stack. If that is too opaque, > which it will probably will be if app is Core Data, consider the "Dave > Fernandes Override -willChangeValueForKey: Trick": It's not. A change from the undo manager has a completely different stack trace, where the undo manager sends a synchronous notification via NSNotificationCenter. This one seems to be something in the run loop (a queued task?) triggering a direct call to -[NSDocument _checkAutosavingThenUpdateChangeCount:]_block_invoke_2 () which is most definitely something internal and private and not something my code has (knowingly) set up. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSStackView layout issues
> Begin forwarded message:
>
> Subject: Re: NSStackView layout issues
> From: SevenBits
> Date: November 24, 2014 at 7:53:15 PM EST
> To: Jonathan Mitchell
>
> Hello Jonathan,
>
> That seems to have done the trick, thank you.
>
> That you for directing me to TSStackView, I will take a look at it.
>
> — SevenBits
>
>> On Nov 24, 2014, at 5:17 AM, Jonathan Mitchell
>> wrote:
>>
>>
>>
>>> On 23 Nov 2014, at 16:48, SevenBits wrote:
>>>
>>> Hello Cocoaphiles, ;)
>>>
>>> I've just started experimenting with NSStackView, and I'm having a very
>>> interesting problem which I can't solve. I've scoured the auto layout
>>> guides on Apple's website as well as the NSStackViewdocumentation, and
>>> can't seem to find anything.
>>>
>>> From what I understand, the intrinsic content size should prohibit the view
>>> from getting shrunk this small. I'm not too familiar with NSStackView, so
>>> any help would be appreciated.
>>>
>> I think you will find that NSScrollView -intrinsicContentSize will return
>> {NSViewNoIntrinsicMetric, NSViewNoIntrinsicMetric}.
>> i.e: a scroll view doesn’t report an intrinsic content size.
>>
>> NSStackView calls -fittingSize to determine the size for its subviews.
>> If you add a subview to a vertical NSStackView without a fully constrained
>> height it collapses to zero - ish.
>> Often, if you ask XCode to add contains to your view it will not fully
>> constrain the height of the view.
>> This cases them to misbehave in an NSStackView.
>>
>> So the point is add some constraints!
>> NSStackView is supremely useful once you get your head around the constraint
>> basics.
>>
>> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>>
>> NSLog(@"- intrinsicContentSize : %@",
>> NSStringFromSize(self.textScrollView1.intrinsicContentSize));
>> NSLog(@"- fitting size: %@",
>> NSStringFromSize(self.textScrollView1.fittingSize));
>>
>> self.textScrollView1.translatesAutoresizingMaskIntoConstraints = NO;
>> self.textScrollView2.translatesAutoresizingMaskIntoConstraints = NO;
>>
>> self.stackView.alignment = NSLayoutAttributeWidth;
>>
>> [self.stackView addView:self.textScrollView1
>> inGravity:NSStackViewGravityTop];
>> [self.stackView addView:self.textScrollView2
>> inGravity:NSStackViewGravityTop];
>>
>> NSDictionary *views = NSDictionaryOfVariableBindings(_textScrollView1,
>> _textScrollView2);
>> [self.stackView addConstraints:[NSLayoutConstraint
>> constraintsWithVisualFormat:@"V:[_textScrollView1(==_textScrollView2)]"
>>
>> options:0
>>
>> metrics:nil
>>
>> views:views]];
>> }
>>
>> I use the following with view -hidden bindings to manipulate complex view
>> stacks
>>
>> https://github.com/mugginsoft/TSStackView
>>
>> Jonathan
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com
>>
>> This email sent to sevenbitst...@gmail.com
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
