I have an NSWindow subclass (GameWindow) containing an NSOpenGLView subclass (GameView).
The app is windowed (does not go fullscreen).
An OpenGL animation in GameView is fired ~30 times a second by a timer.
For presentation reasons, the GameView animation MUST continue regardless of what else is happening in the app. The only time it should stop is in the case of a fatal error.
I need to present various "modal" Cocoa windows (e.g. choose new game, confirm quit, etc.) while the animation in GameWindow continues. Some of these could be sheets, but major ones need to appear as standalone windows (complete with WebViews).
MY QUESTION: how can I display these "dialog" windows such that my app timer continues to fire, my animation continues, but user input to the GameView in the GameWindow is blocked until the "dialog" window is dismissed by the user?
(I need to support Tiger + Leopard at this time).
Have you tried the regular sheet/dialog techniques? They should work fine for this situation. Timers are scheduled as part of the run loop, which doesn't stop when you have a modal sheet or window, so it should be able to continue on rendering in the background while events are blocked.
[NSApp beginSheet:sheetWindow modalForWindow:mainWindow modalDelegate:nil didEndSelector:NULL contextInfo:nil];
(Except fill in your own delegate and end selector if needed.)
If you want to keep the current modal windows (without moving to sheets), you can try scheduling the NSTimer yourself in something besides the default runloop mode (NSDefaultRunLoopMode), which hangs as soon as that runloop stops running.
Related
The problem: Attempting to display a window with text from applicationWillFinishLaunching will NOT draw itself if other processor-intensive non-UI code is immediately called.
Background: I have a helper app that when launched may or may not interact with the end user. While it is "deciding" if it needs to put up a window to ask user questions, there may be anywhere from 1 second to 10 seconds that elapse (after launch it's off in non-UI capable library code communicating over the internet).
So I wanted to be kind to the user and put up a "mini-alert"* window with "working, please wait...", prior to heading into that library code, which I will dismiss once that processing has elapsed.
It seems as if the app itself doesn't have time after launch to even draw this mini-alert (it's just an NSWindow, with an NSView, some text, and no buttons).
If after the library code returns and want to put up either an error alert or a query window for the user -- then at that point the mini-alert draws as expected. However, if I close the mini-alert (see below) and then put up an NSAlert -- the mini-alert doesn't have enough time to dismiss itself.
- (void)applicationWillFinishLaunching:(NSNotification *)notification
{
[NSApp activateIgnoringOtherApps:YES];
briefAlertWindowController = [[NSWindowController alloc] initWithWindowNibName:#"BriefAlertWindow"];
[[briefAlertWindowController window] center];
[briefAlertWindowController showWindow:self ];
[[briefAlertWindowController window] orderFront:self ];
[[briefAlertWindowController window] display];
[[briefAlertWindowController window] makeKeyAndOrderFront:nil];
}
and dismissing the mini-alert:
- (void)dismissMiniAlert
{
NSWindow * theWindow = [briefAlertWindowController window];
[theWindow orderOut:nil];
}
NOTE that neither NSWindow not NSWindowController have been derived/subclassed for this mini-alert.
I'm using the term "mini-alert", because I've noticed people get annoyed about the concept of a "splash screen". While the functionality IS similar -- I'm really just trying to let the user know that an unavoidably long operation is taking place.
It sounds like a threading problem. The splash window can't draw itself on the main thread because the main thread is busy doing the processor-intensive operation. Properly, your processor-intensive stuff should all be happening on a background thread. If you can't do that, you need at least to get off the main thread long enough to give the runloop a chance to draw your window. Just introduce a delay.
When I try launching my app through Spotlight without building it through XCode, the NSWindowController displays the unmodified nib (with the standard gray background color, etc) for a split second before windowDidLoad finishes. This looks awful, since views are in the wrong places and aren't colored correctly.
I tried removing everything from windowDidLoad to see if something in there was slowing it down, but that didn't improve things. I also tried moving the setting of the background color to initWithWindowNibName, but that didn't help either.
Is there a way to delay showing the window while it finishes loading?
Here's the code I'm using to initialize the NSWindowController:
self.windowController = [[WindowController alloc] initWithWindowNibName:#"WindowController"];
[self.windowController showWindow:self];
[[self.windowController window] makeKeyAndOrderFront:nil];
Disable NSWindowController's "visible at launch" property in Interface Builder.
(Of course, I post the question then immediately figure out the answer.)
I have a custom view that is a subview of the main window. I have a timer that fires a [self setNeedsDisplay:TRUE] that will update drawing on the view. But from what I can see, if I leave the application on the background and switch to another, it does not reflect the new drawing functions until I click again on the application.
What could I be missing?
Thank you,
Jose.
setNeedsDisplay will not fire if it thinks the user cant see what its drawing for obvious reason. This includes, offscreen and obscured views even when the app is running.
In an app where you might be drawing data over time you would draw all the relevant data while backgrounded out at once when the app resumes.
I have a NSWindow that hosts a WebView that Ive hooked up to a script handler.
Now, when the user clicks a button on a control on the WebView it calls a Objective C method on my object.
In this specific case, the action of the button is to try and close the window hosting the WebView
[[webView window] close];
This usually works, but sometimes i get a SEGFAULT or some other access violation as a result of the event loop trying to dispatcha mouse message to the now destroyed view.
The callstack is horrible when I try to close the window, the even loop has called the window has called the webView, has called my script delegate when I try and close the window. Destruction of an object from a callback from that object is generally, well, dangerous, but I can't figure out how windows should safely be closed as a result of users interacting with views on them.
Istead of closing, can't you try out the API
- (void)orderOut:(id)sender
just check whether your window is visible and orderout that window
if([[webView window] isVisible])
[[webView window] orderOut:self];
The callstack is horrible when I try to close the window, the even loop has called the window has called the webView, has called my script delegate when I try and close the window. Destruction of an object from a callback from that object is generally, well, dangerous, but I can't figure out how windows should safely be closed as a result of users interacting with views on them.
You can use performSelector:withObject:afterDelay: to put off closing the window until 0.0 seconds after the button hit.
In this specific case, the action of the button is to try and close the window hosting the WebView
[[webView window] close];
This usually works, but sometimes i get a SEGFAULT or some other access violation as a result of the event loop trying to dispatcha mouse message to the now destroyed view.
That's not likely. The event loop will only dispatch an event for a window that exists; if you have closed and thereby destroyed a window, no event can arrive at that window, nor at any view that may once have been in it.
It would help if you would edit your question to include the stack trace for that crash.
I know this is an old question, but I'm having a similar issue and I suspect the accepted answer is missing the point. I believe the window hosting the WebView is still one or more of the delegates of the WebView, and delegate methods are being called after the WebView finishes loading, which is after the window is closed.
I was looking for the right way to resolve this… I'll keep looking. :-)
I want to open an overlay window (pop up window) when a user selects a cell in my NSTableView similar to selecting an event in iCal. Selecting the event in iCal shows a Window to edit the event, but does so by smoothly animating the window open and adding an arrow pointing to the even in the underlying calendar. Does anyone know what is being used here? Is this a bunch of hidden/custom APIs or is this available for public use?
The editor pane appears to be a custom borderless, transparent window with a custom view (the view defines the shape and therefore the shadow it casts). Learn more here. You might even use MAAttachedWindow.
Regarding animation, it's as simple as asking the window's animator to animate the frame and the alpha value (grouping them together). You'll probably want to set everything up directly in its "start position" first (ie, while the window is off-screen, set its alpha to zero, and its frame to some smaller version so it "zooms in" a la iCal), then put it on screen and start the grouped animation:
[NSAnimationContext beginGrouping];
[[window animator] setFrame:someNewSlightlyLargerFrame];
[[window animator] setAlphaValue:1.0];
[NSAnimationContext endGrouping];
Once the grouping is ended, the animation will begin (asynchronously) and your code execution will continue. Something to think about is getting everything "staged" first (including making sure the subviews of your window are already updated beforehand, so they don't change in the middle of your animation ... unless you want them to).
So the two separate techniques you need to understand are a custom window and basic Cocoa animation.
If you're using OSX 10.7 and above, NSPopover will do the job you're looking for.
Are you talking about selecting even from a list at the bottom of iCal app?
Not sure what exactly you are referring to but there is an api for animating transformations within a timespan.
Looking at other Apple's applications, Apple's developers utilize the same api available to anyone else (mostly I guess). There is lots of stuff that can be customized and Apple customizes whatever is required until it looks right from design point of view ...