Re: NSExceptionHandler and "Internal Error" dialog

[Matt Jacobson via Cocoa-dev]

Hey James,

> On May 28, 2021, at 6:54 PM, James Walker via Cocoa-dev 
>  wrote:
> 
> When an uncaught exception is raised, I want to log some information about it 
> but let it continue on as normal.  But when I use NSExceptionHandler, an 
> uncaught exception displays an "Internal Error" modal dialog with buttons 
> "Show Details", "Crash", and "Continue".  I don't see any explicit mention of 
> this dialog in the API docs for NSExceptionHandler or in the "Exception 
> Programming Topics" guide.  I suppose that is what is meant when the 
> documentation of the method setExceptionHangingMask: talks about cases that 
> will "halt execution for debugging".  But I set this mask to 0, so I would 
> think it would never show the dialog, yet it does.  I have an 
> NSExceptionHandlerDelegate whose delegate methods always return NO, meaning 
> do not handle or log the exception.  Is there any way to just watch 
> exceptions go by without showing this dialog?

Without commenting on the wisdom of blowing past exceptions 😉, I’ll note that:

1. NSExceptionHandler doesn’t allow you to prevent uncaught exceptions (whether 
truly uncaught or caught by one of AppKit’s last-resort catches) from being 
reported to +reportException:.  It in fact goes out of its way to make sure it 
does not impede this

2. Bt… the default behavior in Cocoa of an uncaught exception is to ignore 
it.  You’re seeing this dialog because you have the user default 
`NSApplicationShowExceptions` set somewhere.  (Use `defaults find` to help find 
out where.)  It’s not on by default, but you may have turned it on at some 
point because of the aforementioned wisdom

HTH,

Matt
___

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: NSExceptionHandler and "Internal Error" dialog

[Matt Jacobson via Cocoa-dev]

> On May 28, 2021, at 8:41 PM, James Walker  wrote:
> 
> On 5/28/21 4:21 PM, Matt Jacobson wrote:
>> On May 28, 2021, at 6:54 PM, James Walker via Cocoa-dev 
>>  wrote:
>>> When an uncaught exception is raised, I want to log some information about 
>>> it but let it continue on as normal.  But when I use NSExceptionHandler, an 
>>> uncaught exception displays an "Internal Error" modal dialog with buttons 
>>> "Show Details", "Crash", and "Continue".  I don't see any explicit mention 
>>> of this dialog in the API docs for NSExceptionHandler or in the "Exception 
>>> Programming Topics" guide.  I suppose that is what is meant when the 
>>> documentation of the method setExceptionHangingMask: talks about cases that 
>>> will "halt execution for debugging".  But I set this mask to 0, so I would 
>>> think it would never show the dialog, yet it does.  I have an 
>>> NSExceptionHandlerDelegate whose delegate methods always return NO, meaning 
>>> do not handle or log the exception.  Is there any way to just watch 
>>> exceptions go by without showing this dialog?
>> Without commenting on the wisdom of blowing past exceptions 😉, I’ll note 
>> that:
>> 
>> 1. NSExceptionHandler doesn’t allow you to prevent uncaught exceptions 
>> (whether truly uncaught or caught by one of AppKit’s last-resort catches) 
>> from being reported to +reportException:.  It in fact goes out of its way to 
>> make sure it does not impede this
>> 
>> 2. Bt… the default behavior in Cocoa of an uncaught exception is to 
>> ignore it.  You’re seeing this dialog because you have the user default 
>> `NSApplicationShowExceptions` set somewhere.  (Use `defaults find` to help 
>> find out where.)  It’s not on by default, but you may have turned it on at 
>> some point because of the aforementioned wisdom
>> 
> Thank you very much.  NSApplicationShowExceptions was indeed turned on in the 
> global domain; I probably did that years ago and forgot about it.  And I 
> didn't know about Cocoa defaulting to ignoring uncaught exceptions, I thought 
> it would kill the app like uncaught C++ exceptions do.  So I wasn't expecting 
> to "blow past" exceptions, I was expecting to crash.

Then you might be interested in another user default: 
`NSApplicationCrashOnExceptions`.  Basically, it pretends you always click the 
“Crash” button in that dialog.

Again, not on by default, so don’t rely on it!

Matt
___

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: "A build only device cannot be used to run this target" appearing with "Any Mac" scheme

[Matt Jacobson via Cocoa-dev]

Hey Gabriel,

> On Aug 23, 2021, at 1:48 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have a screensaver that compiles and runs fine when I use the active scheme 
> "My Mac".
> However, when I switch to "Any Mac (Apple Silicon, Intel)", I get the error 
> message 
>   "A build only device cannot be used to run this target"
> in Xcode immediately.
> 
> Maybe, the following info is related to this error message, maybe not:
> The scheme is a bit uncommon, perhaps, because it has a Pre-action in the Run 
> tab
> (which copies the .saver bundle into ~/Library/Screen Savers), 
> and in the Run section the Executable is set to "System Preferences.app".
> (It works fine under the "My Mac" scheme.)

That pop-up actually has two halves: first, a scheme, and second, a run 
destination.

“Any Mac” and “My Mac” are run destinations, not schemes.  But, as you’ve seen, 
“Any Mac” is a special “build-only” run destination that only supports 
building, not running.

You should be able to pair your scheme with either of those run destinations.  
(If not, check the ARCHS (“Architectures”) setting of your targets.  Normally, 
it should be set to $(ARCHS_STANDARD) (“Standard Architectures (Apple Silicon, 
Intel)”) — which is the SDK default anyway.)

If you wish to build your scheme with the “My Mac” run destination and make 
sure you’re building for both architectures, check out the ONLY_ACTIVE_ARCH 
(“Build Active Architecture Only”) build setting.  When YES, Xcode will build 
only for the architecture of your run destination; when NO, it’ll build for all 
valid architectures.

Normally, ONLY_ACTIVE_ARCH is set to YES for debug builds and NO for release 
builds.  The idea is to avoid slowing down your edit-build-debug cycle by 
building code you’re not going to run.  However, some people like to change 
that.

HTH,

Matt
___

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: "A build only device cannot be used to run this target" appearing with "Any Mac" scheme

[Matt Jacobson via Cocoa-dev]

> On Aug 23, 2021, at 2:20 PM, Gabriel Zachmann  wrote:
> 
> Hi Matt,
> 
> thanks a lot for your quick response. It clarifies a few things .. but see 
> below.
> 
>> 
>> That pop-up actually has two halves: first, a scheme, and second, a run 
>> destination.
>> 
>> “Any Mac” and “My Mac” are run destinations, not schemes.  But, as you’ve 
>> seen, “Any Mac” is a special “build-only” run destination that only supports 
>> building, not running.
>> 
>> You should be able to pair your scheme with either of those run 
>> destinations.  (If not, check the ARCHS (“Architectures”) setting of your 
>> targets.  Normally, it should be set to $(ARCHS_STANDARD) (“Standard 
>> Architectures (Apple Silicon, Intel)”) — which is the SDK default anyway.)
> 
> That is the case in my Build Settings.
> 
>> 
>> If you wish to build your scheme with the “My Mac” run destination and make 
>> sure you’re building for both architectures, check out the ONLY_ACTIVE_ARCH 
>> (“Build Active Architecture Only”) build setting.  When YES, Xcode will 
>> build only for the architecture of your run destination; when NO, it’ll 
>> build for all valid architectures.
> 
> This is set to "Yes" in the Debug case, and "No" in the Release case.
> 
> 
> Do you have any other idea what might be causing this error message ?
> Is there a way to compile & run a universal app from Xcode directly?
> Or do I have to remember to switch to the "Any Mac" destination before I 
> distribute an app?
> (I'm talking about macOS apps.)

It’s definitely doable.  Let me attempt to summarize:

First, you cannot run against the “Any Mac” destination, by design.  (That is 
what’s causing the error message.  It’s a build-only destination, and you’re 
trying to run on it.)  You can run against the “My Mac” destination.

Second, let’s think about “My Mac”.  Given the settings you described above—a 
debug build will be active-architecture-only.  If you’re on an Intel Mac, that 
means Intel-only; if you’re on an ARM Mac, that means ARM-only.

All together, that means: if you want to run, you must use the “My Mac” run 
destination—and if you want the build used for that run to be fat (i.e., both 
Intel and ARM), then either of these two things should work:

1. Change your scheme to Release (this usually enables compiler optimizations, 
somewhat hampering debuggability)
2. Change ONLY_ACTIVE_ARCH to NO for debug (this makes builds take longer debug 
mode, since both architectures must be built — probably not a big deal for 
small projects)

===

Additionally—as you suggest—there is a third way.  You can use { “My Mac”, 
Debug, ONLY_ACTIVE_ARCH=YES } for local development/debugging, and use “Any 
Mac” for building the app to distribute.

That includes “distributing” test versions to Macs of the opposite architecture 
from you.  (Of note here: the “active architecture” of “Any Mac” is considered 
to be *both* architectures; in other words, “Any Mac” is essentially unaffected 
by ONLY_ACTIVE_ARCH.  So a debug build against “Any Mac” will be fat.)

Matt
___

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: ARC and C++ structures

[Matt Jacobson via Cocoa-dev]

Hi Tom,

> On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev 
>  wrote:
> 
> I have a multiple platform application (Windows, Mac, GTK) that is 
> primarily organized using C++ with Objective-C used for the 
> Mac-specific interface. I recently switched to use ARC (as we are 
> using Scintilla which recently switched to ARC). However, I am 
> getting a zombied release of an NSWindow instance. So far as I 
> can tell, the memory handling of this seemed to be fine pre-ARC. 
> Unfortunately, because it's an NSWindow, the Instruments output 
> for it has 100's of toolbox calls, so it's very hard to tell where the 
> extra release is. What should I be looking for? 
> 
> Just to describe this, there's an EWindow C++ structure which has 
> the NSWindow * as a member (under Mac OS; it's an HWND under 
> Windows and Widget under GTK). It's after the delete of the 
> EWindow that things go south. I'm assuming that ARC is putting in a 
> release, but I haven't really seen any good description of how ARC 
> interacts with C++. A release there seems fine---the question is 
> where is the earlier (apparently erroneous) release.

ARC will insert code at the end of your C++ destructor to release any strong id 
members.

One possible wrinkle is the default release-when-close behavior of NSWindow.  
By default, when an NSWindow is `-close`d (which can only happen once in its 
lifetime), AppKit sends it a `-release`.  The idea is that this release 
balances the initial `+alloc`.

However, this is somewhat incompatible with ARC, which doesn’t know about this 
special behavior and will attempt to insert its own release to balance the 
alloc.

Here is an example of a program that works perfectly fine under MRR but crashes 
under ARC:

#import 

NSWindow *window;

int main(void) {
@autoreleasepool {
window = [[NSWindow alloc] 
initWithContentRect:NSMakeRect(0., 0., 100., 100.) 
styleMask:NSWindowStyleMaskTitled backing:NSBackingStoreBuffered defer:NO];
[window makeKeyAndOrderFront:nil];
[window close];
window = nil;
}
}

You can disable this behavior by changing the `releasedWhenClosed` property of 
the window to `NO`:

[window setReleasedWhenClosed:NO];

Matt

___

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: ARC and C++ structures

[Matt Jacobson via Cocoa-dev]

> On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø  wrote:
> 
> 
>> On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> By default, when an NSWindow is `-close`d (which can only happen once in its 
>> lifetime), 
> 
> Interesting. If the NSWindow is retained elsewhere, can it not be ordered in 
> again? Appreciate any details you can provide :)

I was wrong about this detail.  The window can definitely be ordered in again, 
and any subsequent `-close` does *not* issue a `-release`, even if the window 
`isReleasedWhenClosed`.  (How confusing.)

So ignore the parenthetical part, but do `setReleasedWhenClosed:NO` your 
windows.

Matt
___

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: App can't be opened

[Matt Jacobson via Cocoa-dev]

Hey,

> On Sep 15, 2021, at 11:38 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Thanks so much! I guess that missing symbol explains the crash.
> 
> BTW: is it possible, to make Xcode produce an error message when I am using 
> symbols that are not available on the deployment target?
> (unless they are guarded by @available() ...)

Normally, that does happen automatically.

However, in this case, it appears that AVAudioSessionInterruptionNotification 
is missing an availability annotation for macOS.  The compiler interprets this 
as meaning “symbol is always available” and doesn’t warn you.

Since the online docs say that AVAudioSessionInterruptionNotification only 
became publicly available in macOS 11.0, I suspect this is a bug in the 
AVFAudio headers.  (This is a somewhat frequent occurrence as iOS APIs get 
moved over to macOS—often to support Catalyst—without a thorough audit of the 
headers.)

Matt
___

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: Accessibility - Smart Invert and images.

[Matt Jacobson via Cocoa-dev]

Check out this property on UIView:

>

or this “modifier” method on SwiftUI View:

>

Matt

> On Sep 29, 2021, at 12:20 PM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> According to the docs, Smart Invert on iOS isn’t supposed to invert images of 
> certain types.  However, it is in my app and I’ll be damned if I can find out 
> any documentation that would indicate the the rules around what it does and 
> what it doesn’t invert.
> 
> Does anyone here have any experience with this?
> 
> Thanks in advance.
> Alex Zavatone
> ___
> 
> 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/mhjacobson%40me.com
> 
> This email sent to mhjacob...@me.com

___

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: Accessibility UIContentSizeCategory or current accessibility font setting

[Matt Jacobson via Cocoa-dev]

Hey Alex,

> On Oct 17, 2021, at 2:51 PM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> We’ve got a situation where we need to check the current accessibility font 
> size enum and apply custom settings to some attributed fonts.  I’ve seen that 
> there is a way to check the current dynamic text size using SwiftUI, but I 
> haven’t seen how to do it using UIKit.
> 
> I’ve seen that UIContentSizeCategory exists, but no idea how to see what the 
> current value is.
> 
> Is anyone aware how to do this?  TIA.

Have you tried this?

[UIApp preferredContentSizeCategory]

(Don’t forget to observe changes: UIContentSizeCategoryDidChangeNotification.)

Matt
___

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: Problem with rangeOfString and Umlauts

[Matt Jacobson via Cocoa-dev]

> On Mar 11, 2022, at 12:17 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
> Well, SSIA.
> In more detail, I've got two strings:
> 
> file_basename = @"Morgendämmerung (1)"
> info_item = @"Morgendämmerung"
> 
> This code
> 
>NSString * prefix = [ info_item commonPrefixWithString: file_basename 
> options: NSCaseInsensitiveSearch ];
>unsigned int prefix_len = (unsigned int) [prefix length];
> 
> yields prefix_len = 15
> as it should.
> 
> The problem arises with this line of code:
> 
>NSRange space_in_filename = [file_basename rangeOfString: @" " options: 
> NSDiacriticInsensitiveSearch|NSCaseInsensitiveSearch|NSWidthInsensitiveSearch];
> 
> which yields space_in_filename.location = 16 !
> 
> This thwarts the rest of the code, which, in this case, would expect 
> space_in_filename.location = 15.
> 
> Needless to say that with strings that do not contain Umlauts, the call of 
> rangeOfString:options: works as expected, i.e., in the above example 
> space_in_filename.location is as expected (i.e., first character has 
> location=0).
> 
> I have also tried localizedStandardRangeOfString, with the same effect.
> 
> Any ideas what I can do?

It’s hard to tell from the above snippet, but I suspect your strings are 
different in normalization.  Specifically, I suspect that file_basename uses 
two Unicode codepoints for the ä, and info_item uses only one.

As an experiment, try running both strings through 
-precomposedStringWithCanonicalMapping before doing your comparisons.  This 
method returns a new precomposed string—it doesn’t alter the receiver.

Matt
___

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