Re: MacOS: nonmodal NSAlert panel

[Ben Kennedy via Cocoa-dev]

> On 12 May 2021, at 11:17 am, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I'd like to present an informational alert for n seconds then dismiss it 
> without user interaction. But I don't see any way to dismiss, terminate, 
> cancel, invalidate, etc. an NSAlert object.

I recently did that exact thing, like this:

> let alert = NSAlert()
> // ...
> 
> var countdown = 10
> func updateMessage() {
> alert.informativeText = "This message will dismiss in \(countdown) 
> second\(countdown == 1 ? "" : "s")."
> countdown -= 1
> }
> let timer = Timer(timeInterval: 1.0, repeats: true) { timer in
> if countdown == 0 {
> timer.invalidate()
> NSApp.abortModal()
> } else {
> updateMessage()
> }
> }
> updateMessage()
> RunLoop.main.add(timer, forMode: .common)
> 
> alert.runModal()

The key is `abortModal()`.

-ben

___

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: MacOS: nonmodal NSAlert panel

[James Walker via Cocoa-dev]

On 5/12/21 11:17 AM, Carl Hoefs via Cocoa-dev wrote:

I had thought it was possible on MacOS to run an NSAlert panel nonmodally...

I'd like to present an informational alert for n seconds then dismiss it 
without user interaction. But I don't see any way to dismiss, terminate, 
cancel, invalidate, etc. an NSAlert object.

I know this is possible in iOS, but is there no way to do this in MacOS, other 
than displaying/hiding an NSPanel of my own?


An alternative would be CFUserNotificationDisplayNotice, which takes a 
timeout period as a parameter.


___

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: MacOS: nonmodal NSAlert panel

[Keary Suska via Cocoa-dev]

I believe Apple uses NSPopOver for non-modal alerts and dialogs, which can 
automatically dismiss when the user clicks outside the popover.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

> On May 12, 2021, at 12:17 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I had thought it was possible on MacOS to run an NSAlert panel nonmodally...
> 
> I'd like to present an informational alert for n seconds then dismiss it 
> without user interaction. But I don't see any way to dismiss, terminate, 
> cancel, invalidate, etc. an NSAlert object.
> 
> I know this is possible in iOS, but is there no way to do this in MacOS, 
> other than displaying/hiding an NSPanel of my own?
> 
> -Carl
> 
> ___
> 
> 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/cocoa-dev%40esoteritech.com
> 
> This email sent to cocoa-...@esoteritech.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: MacOS: nonmodal NSAlert panel

[Jens Alfke via Cocoa-dev]

> On May 12, 2021, at 11:17 AM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> I had thought it was possible on MacOS to run an NSAlert panel nonmodally…


Alerts are modal by definition, per the HIG (IIRC). If you want a non-modal 
panel, it wouldn't be an alert; you'd have to implement it yourself using an 
NSPanel.

—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

MacOS: nonmodal NSAlert panel

[Carl Hoefs via Cocoa-dev]

I had thought it was possible on MacOS to run an NSAlert panel nonmodally...

I'd like to present an informational alert for n seconds then dismiss it 
without user interaction. But I don't see any way to dismiss, terminate, 
cancel, invalidate, etc. an NSAlert object.

I know this is possible in iOS, but is there no way to do this in MacOS, other 
than displaying/hiding an NSPanel of my own?

-Carl

___

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: Exception not being caught in try statement

[Mark Allan via Cocoa-dev]

Hi all,

Thanks to everyone for their suggestions. I spent far too much time working 
around this bug, but have finally got to the bottom of the original issue.

It turns out this is a known issue with some other apps as well, and (thanks to 
https://trac.cyberduck.io/ticket/11231#comment:25 
 ) can be fixed by removing 
an obscure preference key from the User Defaults system.

I was able to reproduce the issue by setting the 
__NSDisableSharingTextTabInstance key to YES using the "defaults write" command.

I've solved it by removing that key in my -applicationDidFinishLaunching method:
[[NSUserDefaults standardUserDefaults] removeObjectForKey: 
@"__NSDisableSharingTextTabInstance"];

Looks like someone has already submitted a bug report to Apple for it 
(https://openradar.appspot.com/FB8930278 
 ) so I'm just posting this here in 
case it helps anyone else in the future.

Best regards,
Mark 

> On 29 Mar 2021, at 7:01 pm, Martin Wierschin via Cocoa-dev 
>  wrote:
> 
> Breaking the RTFD loading process down into subtasks is a good idea. It might 
> be worth trying to sidestep the issue using NSAttributedString. You can try 
> loading the data yourself as Mike suggested and then use initWithRTFD or 
> initWithRTFDFileWrapper. Once you have the text in an attributed string you 
> can swap its content into your NSTextView/NSTextStorage using 
> -replaceCharactersInRange:withAttributedString:
> 
> However, I suspect the problem will remain. The exception is coming from 
> Apple's internal NSRTFReader class, which we can be reasonably certain is 
> utilized by all RTF/RTFD loading code paths. To really fix this you're 
> probably going to be stuck with ugly code that either:
> 
> 1. Preprocess the RTFD to remove the data that Apple's code can't handle, eg: 
> strip tab stops as someone else suggested.
> 2. Use method swizzling to patch Apple's buggy methods at runtime, eg: 
> replace -[NSRTFReader defaultParagraphStyle] to avert the conditions that 
> lead to the exception, before it gets thrown in the first place.
> 
> One other potential debugging aid: NSExceptionHandler. You can register your 
> own handler, perhaps in a way that prevents AppKit from killing your app 
> outright when an exception occurs (this used to be possible but I don't know 
> the current behavior). But as Mike said, this isn't a real solution for 
> shipping software. Generally speaking once an app has thrown an exception its 
> state can't be relied upon. So you should only use this for testing to gather 
> additional debug information.
> 
> ~Martin Wierschin
> 
>> On Mar 26, 2021, at 11:22 AM, Mike Abdullah via Cocoa-dev 
>>  wrote:
>> 
>> This does seem quite surprising. However, here’s the thing: this code is 
>> very strange approach to take.
>> 
>> Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism 
>> except where explicitly stated and supported. You’re trying to use them, 
>> which is asking for trouble. The system doesn’t guarantee proper handling of 
>> memory if an exception does throw.
>> 
>> Number 2: Your error handling approach is back-to-front. You’re trying an 
>> operation, seeing if it fails, then attempting to guess from the current 
>> state (which might have changed in the meantime) why it might have failed.
>> 
>> Instead, use the proper error APIs and approach:
>> 
>> 1. Load the data from disk, e.g. +[NSData 
>> dataWithContentsOfURL:options:error:]
>> 
>> If that fails you can introspect the error to your heart’s content to find 
>> out what went wrong
>> 
>> 2. Load the data into your text view. I’m not sure if there’s an API to do 
>> that in a single step or not, dunno.
>> 
>> I also note that your code explicitly is trying to read an RTFD which if 
>> memory serves can be a document *bundle* format, so perhaps at step 1 you’d 
>> have to go with a file wrapper. But the path you specify is .rtf so I’m 
>> guessing you really do have a basic file and can load it as data.
>> 
>> Mike.
>> 
>>> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev 
>>>  wrote:
>>> 
>>> Hi folks,
>>> 
>>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>>> to gain additional diagnostics from a user, I wrapped the affected line in 
>>> a try/catch block.  For two users it resolve the crash, but for a third, 
>>> it's still crashing at the same point!
>>> 
>>> The crash occurs when a user attempts to open the "About" window from my 
>>> app's main menu item. I'm not using the standard about panel as there's a 
>>> few additional items I need to display, one of which is an NSTextView which 
>>> I populate with the contents of an RTF file from within the app bundle.
>>> 
>>> I've symbolicated the crash log to find it's happening when populating that 
>>> TextView. The line in question now reads as follows:
>>> 
>>> @try {
>>> [self.aboutBox.creditsTextView