Block until NSAlert (shown as a modal sheet) is dismissed - objective-c

I'm currently learning (by doing) objective-c by implementing a feature I felt is missing in the Titanium Appcelerator Desktop SDK: A way to do modal dialog with custom button texts and optionally to display them as a "sheet".
All is dandy and working, however, when displaying the NSAlert as a "sheet" my method that's creating the alert returns immediately and that's what I want to prevent.
The method's creating the alert returns an int (the return code from the NSAlert).
The code inside basically boils down to:
int returnCode = -1;
if (displayAsSheet) {
[alert beginSheetModalForWindow:nativeWindow modalDelegate:delegate didEndSelector:#selector(alertDidEnd:returnCode:contextInfo:) contextInfo:nil];
} else {
returnCode = [alert runModal];
}
return returnCode;
The modalDelegate is an object that's implementing the needed:
- (void)alertDidEnd:(NSAlert *)alert returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo;
and for now it just does a NSLog of the returnCode.
So my question is:
How can I block my method from returning until the "sheet" has been dismissed?
Or am I going about this the wrong way?

You must start a modal session for you sheet after showing it and stop the session after closing sheet.
Check this: https://github.com/incbee/NSAlert-SynchronousSheet, I think it will be helpfull.

You could use this after beginSheetModalForWindow:...:
[[NSRunLoop mainRunLoop] runMode:NSModalPanelRunLoopMode beforeDate:[NSDate distantFuture]]
However, it will make any other windows in your app unusable until the sheet is dismissed. It would be better not to block those windows.

my method that's creating the alert returns immediately
I believe that's because, as #Josh says, the sheet is running modal only relative to the window to which it is attached; it is not freezing the entire app. Therefore, as soon as beginSheetModal... executes, the rest of your method continues to run, concluding with return returnCode (here returning -1), without waiting for the user to respond to the alert.
The return code is a stand-in for which button on the alert panel the user ends up pushing (NSAlertFirstButtonReturn, NSAlertSecondButtonReturn, etc. -- they're listed at the end of the NSAlert class ref). You use it in your alertDidEnd method to act upon whichever button the user pushed to dismiss the alert. That's why the alertDidEnd selector includes the returnCode.
On the other hand, when you use the runModal method in your else block, you need to explicitly call alertDidEnd and feed it the number returned when the runModal method ends -- which is when the user dismisses the alert.
Here's a revised version of your code:
int returnCode = -1;
if (displayAsSheet) {
[alert beginSheetModalForWindow:nativeWindow modalDelegate:delegate didEndSelector:#selector(alertDidEnd:returnCode:contextInfo:) contextInfo:nil];
// The selector alertDidEnd has the returnCode int. The alert will then set that code to whatever the user chooses, and will send the altered int on to alertDidEnd.
}
else {
// Here, everything stops once runModal is called, until the user dismisses the alert, at which time the runModal method returns the int representing the button the user pushed, and you assign the return to your variable "returnCode."
returnCode = [alert runModal];
[self alertDidEnd:alert returnCode:returnCode contextInfo:nil];
}
// Omit the line returning the returnCode.
Then the alertDidEnd method does something like this:
- (void)alertDidEnd:(NSAlert *)alert returnCode:(NSInteger)returnCode contextInfo:(void *)contextInfo {
switch (returnCode) {
case NSAlertFirstButtonReturn:
// Do whatever should happen when first button is pushed.
break;
case NSAlertSecondButtonReturn:
// Do whatever should happen when second button is pushed.
break;
default:
break;
}
// Unfreeze things.
[[NSApplication sharedApplication] stopModal];
}
By the way, there is a way of running a sheet and freezing the entire app, not just the window to which the sheet is attached, if that's what you want: modal tips

You're thinking about this slightly the wrong way. If your method were able to wait for the sheet to end, the app's event loop would be blocked and there would be no way for the user to interact with the UI. When you use runModal for the alert, a new run loop is created to handle the alert -- this is why nothing else can be done to the app. The point of the sheet option is to allow the user to do other things while the alert is displayed -- i.e., it expressly does not take over the event handling.
You could look into faking the sheet by attaching a child window.

You could try to set a boolean that freezes anything you want to freeze on your app (set freeze = YES) until the sheet is removed (set freeze = NO).
In the general case, you don't need to block a method : you just want some things not to happen until the user has made a choice.
For example, I have an app that uses gyroscope. It has some behaviour with, and some other behaviour without.
So I have a boolean that is used in any method that uses the gyro data to route the behaviour to the good one. My useGyro Boolean is NO when : the user is choosing what kind of hardware feature it want to enable or not, and when gyro is not available on the device.
The same thing with a mapView I have : when the user is aked by the system if it wants to be located, there is a moment where I freeze any behaviour using the user location. When he has made his choice, I change that bool value.

Related

Menu Bar App Never Becomes Reactivated

I'm building a Mac app that only sits in the menu bar with no dock item and no key window and no main menu (it's LSUIElement in the info.plist is set to YES). When I first launch the app, applicationDidBecomeActive: is called, as I expect. However, once another app gains focus, applicationDidBecomeActive: is never called again.
This prevents a text field I have within my app from becoming the first responder. When I first open the app, the text field is editable:
But after another app comes to the foreground, the text field is not editable:
What I've tried:
When the menu is opened, menuWillOpen: is called on the NSMenu's delegate. I've tried placing the following with no success:
[NSApp unhide];
[NSApp arrangeInFront:self];
[NSApp activateIgnoringOtherApps:YES];
[NSApp requestUserAttention:NSCriticalRequest];
[[NSRunningApplication currentApplication] activateWithOptions:NSApplicationActivateIgnoringOtherApps];
[[NSRunningApplication currentApplication] unhide];
I think the issue is probably related to not having any windows to bring to the front. I feel like I'm grasping at straws here. Any help would be greatly appreciated.
I think the issue is with that how the runloop operates when a NSMenu is open, so you should try activating the app before you display the menu. If you're having the NSStatusItem display it, I'd suggest doing it yourself like this:
- (void)toggleMenu:(id)sender
{
// App might already be active
if ([NSApp isActive]) {
[self.statusItem popUpStatusItemMenu:self.menu];
} else {
[NSApp activateIgnoringOtherApps:YES];
}
}
- (void)applicationDidBecomeActive:(NSNotification *)notification
{
[self.statusItem popUpStatusItemMenu:self.menu];
}
That should work, but I think though in general you'll have better luck with an actual window instead of a menu.
You probably need to allow your input to -becomeFirstResponder, maybe by overriding -canBecomeFirstResponder or by calling the become method yourself.
You'd likely have to implement/call these methods for whatever view is housing your text input, or maybe tell your input view to become the first responder.
Either way, it smells like a responder chain issue.
Try calling -makeFirstResponder: on your window. NSWindow is usually the start of the NSResponder chain.
- (void)menuWillOpen:(NSMenu *)menu {
[[NSApp mainWindow] makeFirstResponder:yourTextInputField];
}
I'm assuming your text field already accepts first responder since you said your app launches initially with it as the first responder. If not, make sure your text field overrides -acceptsFirstResponder: to return YES
- (BOOL)acceptsFirstResponder {
return YES;
}
Edit: Ah, see that you don't have a key window. It looks like NSMenu actually has a window associated with it though, and it's safe to call -makeFirstResponder:. Some discussion here suggests overriding -viewDidMoveToWindow: on your view containing your text field in the NSMenu like so:
- (void)viewDidMoveToWindow {
[super viewDidMoveToWindow];
[[self window] makeFirstResponder:yourTextInputField];
}

NSPopover - Hide when focus lost? (clicked outside of popover)

I'm using the doubleClickAction of a NSTableView to display a NSPopover. Something like this:
NSInteger selectedRow = [dataTableView clickedRow];
NSInteger selectedColumn = [dataTableView clickedColumn];
// If something was not selected, then we cannot display anything.
if(selectedRow < 0 || selectedColumn < 0)
{
NSLog(#"Invalid selected (%ld,%ld)", selectedRow, selectedColumn);
return;
} // End of something was not selected
// Setup our view controller, make sure if there was already a popover displayed, that we kill that one off first. Finally create and display our new popover.
DataInspectorViewController * controller =
[[DataInspectorViewController alloc] initWithNibName: #"DataInspectorViewController"
bundle: nil];
if(nil != dataPreviewPopover)
{
[dataPreviewPopover close];
} // End of popover was already visible
dataPreviewPopover = [[NSPopover alloc] init];
[dataPreviewPopover setContentSize:NSMakeSize(400.0f, 400.0f)];
[dataPreviewPopover setContentViewController:controller];
[dataPreviewPopover setAnimates:YES];
[dataPreviewPopover showRelativeToRect: [dataTableView frameOfCellAtColumn: selectedColumn row: selectedRow]
ofView: dataTableView
preferredEdge: NSMinYEdge];
Which works just fine. My popovers get created and removed on the cells that I double click on . The problem is, I want to the popover to go away if I click anywhere outside of it (like a single click on another cell). I have been looking around, but for the life of me cannot figure out how to do it.
This is something I would assume is built into a popover, (I'm fairly certain it was in the iOS UIPopoverController class) so I'm just wondering if im missing something simple.
You need to change the property behavior of your popover (in code or on interface builder) to:
popover.behavior = NSPopover.Behavior.transient;
NSPopover.Behavior.transient
The system will close the popover when the user interacts with a user interface element outside the popover.
Read more about this in Apple's documentation.
the .transient flag doesn't work for me.
However I can make things work by the following:
1) Whenever I show my popover I make sure I activate the app
(my app is a menu-bar app, so this doesn't happen automatically)
NSApp.activate(ignoringOtherApps: true)
2) When I click outside the app, then my app will be deactivated. I can detect this in the AppDelegate
func applicationWillResignActive(_ notification: Notification) {
print("resign active")
}
and act accordingly
After calling show(relativeTo:of:preferredEdge:) method,
Add below line
popover.contentViewController?.view.window?.makeKey()
And make sure you set
popover.behavior = .transient
Sorry, I've added solution in Swift.
While transient worked for most cases, it was an issue when the user interacted with elements outside of the application, as the popover would hide but not close.
What finally ended working for me was:
popover.behavior = .semitransient
Now the popover closes when changing app, or interacting with any other element outside of the app. But will not close when interacting with a NSMenu, and maybe won't close either with other interactions.
Quoting from the documentation for NSPopover.Behavior.semitransient:
The exact interactions that cause semi-transient popovers to close are not specified.
Similar to the documentation for NSPopover.Behavior.transient:
The exact interactions that will cause transient popovers to close are not specified.

Modal NSAlert within block not displayed

In my document-based application, I have overridden the method openDocument: in my subclass of NSDocumentcontroller so that I can display my own openPanel. I pass the chosen URLs to the method openDocumentWithContentsOfURL:display:completionHandler:. I use this code for the call:
[self openDocumentWithContentsOfURL:[chosenFiles objectAtIndex:i] display:YES completionHandler:^(NSDocument *document, BOOL documentWasAlreadyOpen, NSError *error) {
if (document == nil)
{
NSAlert* alert = [NSAlert alertWithError:error];
[alert runModal];
}
}];
So I want to display the passed error if nil gets returned as a reference to the document. The problem is, that the program just "freezes" after I press the "Open" button in the open panel. Then I need to manually stop the program with the "stop" button in Xcode. No spinning beach ball appears, though. If I comment the line "[alert runModal]", the program does not freeze any more, but no alert is displayed, of course.
Now the strange thing: The code works sometimes. If I switch from Xcode to my browser and back and I run the program again, it sometimes works flawlessly and the error is displayed. After some time it stops working again. It is unpredictable, but most of the time it doesn't work.
All this sounds like a race-condition to me. It certainly has something to do with the block? But what do I do wrong?
Converting my comment to an answer:
runModel on the main thread.
[alert performSelectorOnMainThread:#selector(runModal) withObject:nil waitUntilDone:NO];
I think runModel needs to be called on the main thread because it's part of the AppKit framework, and it's estentially triggering UI graphics. I believe all calls to the AppKit framework or to any method that manipulates graphics needs to be on the main thread.

detecting when NSUndoManager's alert view is visible

I'm going to describe what I'm trying to do generally (in case there's a better way) and then the stumbling block I've run into (in case my way is the best way).
What I want to do: I want to add an invocation to my undo manager that has a time limit. If the undo is not triggered within the time limit, it won't be available when the device is shaken and thus nothing will happen.
What I'm doing: My approach was to use an NSUndoManager with an NSTimer. When I add the invocation to the undo manager, I kick off a 5-second timer as well. When the timer fires it checks !self.undoManager.isUndoing and if it's true than it goes ahead and removes all actions from the undo manager. Testing it in the simulator works: a shake gesture kicks off the undo before 5 seconds, but not after.
The problem is that if I get a shake gesture under the 5 second limit, the undo manager shows the alert, but if the user waits until after the 5s limit to actually tap the undo button, nothing happens: the timer happily cleared the stack away, even though the alert view was visible.
Is there a way to check and see if the alert view is visible? Best would be if I could figure out if the user hit undo or cancel as well, and clear the undo manager's action stack if the cancel button was pressed.
Or is there a better way besides using a timer in this manner?
Thanks!
Edited to add: My other thought was to capture the shake event myself (via the motionEnded:withEvent: call) and manually manage the alert and undo stack. Thoughts on this compared to the above are also welcome.
I ended up doing what I suggested in my edit—to use motionEnded:withEvent to manually manage the alert and undo. The downside to this is that you don't get the built-in undo alert which has a slightly different style from a UIAlertView and enters the screen with a shaking motion.
The upside is that I now have a undo that expires after 10 seconds. What follows is the general structure of the code in case you want the same.
First, make sure your app can receive shake events and that you have an NSUndoManager you can access. You also need a timer; I have my code set up with an NSTimer that kicks off when the undoable event occurs and lasts 10 seconds. Make sure you add your undo target at the same timer your timer starts so that there's actually something to undo.
Next, implement motionEnded:withEvent like so:
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event {
if (motion == UIEventSubtypeMotionShake && [self.undoManager canUndo]) {
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:#"Undo something?" message:nil delegate:self cancelButtonTitle:#"Cancel" otherButtonTitles:#"Undo", nil];
[alert show];
undoAlertIsVisible_= YES;
}
}
I'm using an ivar called undoAlertIsVisible_ here to track if my alert is on screen.
In your timer's callback, do something like:
if (!self.undoManager.isUndoing && !undoAlertIsVisible_) {
// Clear away the possible undo
[self.undoManager removeAllActionsWithTarget:self];
}
undoTimer_ = nil;
Here we check to see we're not currently undoing and the alert isn't visible. If so, remove the undo actions and set the timer (another ivar) to nil. I'm setting the timer to nil so that I can check whether it's fired in my alert callback, which is here:
- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex {
if (buttonIndex != alertView.cancelButtonIndex) {
if (self.undoManager.canUndo) {
[self.undoManager undo];
}
}
else {
if (!undoTimer_) {
// Timer fired while we were staring at the alert
[self.undoManager removeAllActionsWithTarget:self];
}
}
undoAlertIsVisible_= NO;
}
In the alert callback we either make the undo happen or, if the timer fired while the alert was visible and the alert was canceled, we clear possible undo actions. Otherwise the undo action would hang around after canceling with no timer to clear it.
Hope this helps someone!

Cocoa: Processing thread results, and queuing multiple sheets

I have a multithreaded application that has many concurrent operations going on at once. When each thread is finished it calls one of two methods on the main thread
performSelectorOnMainThread:#selector(operationDidFinish:)
// and
performSelectorOnMainThread:#selector(operationDidFail:withMessage:)
When an operation fails, I launch a sheet that displays the error message and present the user with 2 buttons, "cancel" and "try again". Here is the code I use to launch the sheet:
// failureSheet is a NSWindowController subclass
[NSApp beginSheet:[failureSheet window]
modalForWindow:window
modalDelegate:self
didEndSelector:#selector(failureSheetDidEnd:returnCode:contextInfo:)
contextInfo:nil];
The problem is that if 2 concurrent operations fail at the same time, then the current sheet that is displayed gets overwritten with the last failure message, and then the user's "try again" action will only retry the last failed operation. Ideally, I would like to "queue" these failure sheets. If 2 operations fail at the same time then you should see 2 sheets one right after the other, allowing the user to cancel or retry them individually.
I've tried using:
[NSApp runModalSessionForWindow:[failureSheet window]]
which seems to do what I want, but doesn't work in my situation. Maybe it isn't thread safe?
For example the following code works...
- (void)displaySheet
{
[NSApp beginSheet:[failureSheet window]
modalForWindow:window
modalDelegate:self
didEndSelector:#selector(failureSheetDidEnd:returnCode:contextInfo:)
contextInfo:nil];
[NSApp runModalForWindow:[failureSheet window]];
[NSApp endSheet:[failureSheet window]];
[[failureSheet window] orderOut:nil];
}
// Calling this method from a button press works...
- (IBAction)testDisplayTwoSheets
{
[self displaySheet];
[self displaySheet];
}
However if I have 2 different threaded operations invoke displaySheet (on the main thread) when they are done, I only see one sheet and when I close it the modal session is still running and my app is essentially stuck.
Any suggestions as to what I'm doing wrong?
If you want to queue them, then just queue them. Create an NSMutableArray of result objects (you could use the operation, or the failure sheet itself, or a data object that gives you the information for the sheet; whatever is convenient). In operationDidFinish: (which always runs on the main thread, so no locking issues here), you'd do something like this:
[self.failures addObject:failure];
if ([[self window] attachedSheet] == nil)
{
// Only start showing sheets if one isn't currently being shown.
[self displayNextFailure];
}
Then you'd have:
- (void)displayNextFailure
{
if ([self.failures count] > 0)
{
MYFailure runFailure = [self.failures objectAtIndex:0];
[self.failures removeObjectAtIndex:0];
[displaySheetForFailure:failure];
}
}
And at the end of failureSheetDidEnd:returnCode:contextInfo:, just make sure to call [self displayNextFailure].
That said, this is probably a horrible UI if it can happen often (few things are worse than displaying sheet after sheet). I'd probably look for ways to modify the existing sheet to display multiple errors.
I don't think you're using the "runModalForWindow:" command properly. You wouldn't use both [NSApp beginSheet...] and "runModalForWindow:" at the same time. One is for document modal (where the application keeps running but the window with the sheet is locked) and one is for application modal (which stops everything in the entire app until the sheet is dismissed). You only want the application modal dialog so do this...
For application modal start the window with the following only:
[[failureSheet window] center];
[NSApp runModalForWindow:[failureSheet window]];
Hook the "OK" button and others to regular IBAction methods. They'll get called when a button is pressed. In the IBAction methods you need to do something like this to dismiss the window and process the action:
-(IBAction)okBtnPressed:(id)sender {
[NSApp stopModal];
NSLog(#"ok button");
[[sender window] close];
}