Is there any way to do this?
Right now, I get called, I'm doing things, I have to open a window to ask for input, then I have to FINISH doing things before I return from the original call.
If I enter the runloop for the window, it never ends or returns control to me.
What am I missing here?
I got it -- [NSApp runModalForWindow: window] -- that runs JUST the loop for the window, and when you stop it, control returns to you, leaving the main run loop undisturbed.
What I was doing was [NSApp run], which runs everything, and so when the window issued the stop, everything did.
Related
I'm writing a MEL script which involves opening the grease pencil UI toolbar. I want to remove the close button on that toolbar. I tried doing
GreasePencilTool;
window -edit -tbm 0 greasePencilFloatingWindow;
but get Error: line 2: window: Object 'greasePencilFloatingWindow' not found.
Further tests reveal that running
GreasePencilTool;
window -q -exists greasePencilFloatingWindow;
will return a result of 0.
Running GreasePencilTool; and then window -edit -tbm 0 greasePencilFloatingWindow; at separate times works as expected, as does running window -edit -tbm 0 greasePencilFloatingWindow; when the toolbar is already open.
However, I need to be able to remove the close button immediately when the toolbar opens.
The closest thing I can think of that illustrates what I want to do are Javascript callback functions, where another function can be executed once the current function is finished... but is there a way to do something like that in MEL?
I've also tried using the evalDeferred command without success.
The grease pencil tool is launched asynchronously so the window will not be present for some unknown length of time. This means the best you could do is trigger a function which would check periodically and do it the next time you find the correctly named window; you could attach this to an idle time script job.
It's ugly. But it is probably the only way since there's no event that will notify when thje window arrives. If you do that, make the script job suicide after it fires so it's not sitting there on every idle check till the end of time.
I'm trying to add an observer to the active window (could be any program, not just mine) so that it tells me if it's moving. Here's how I added the observer to the run loop:
AXObserverAddNotification(m_observer, (AXUIElementRef)activeWindow, kAXMovedNotification, (__bridge void*)self);
CFRunLoopAddSource( [[NSRunLoop currentRunLoop] getCFRunLoop], AXObserverGetRunLoopSource(m_observer),kCFRunLoopDefaultMode );
The callback that is associated to the observer currently just prints something to the output window. What I observe is that nothing is output when I'm dragging around the active window (again, this could be any app's window) but as soon as I stop, multiples of the printf results are output. Seems like the calls to the callback are queued until there's some idle time for it to execute all at once.
Is there a way to get the callback executed without waiting for idle time? Maybe a CFRunLoopMode that would do that?
I'm building an application with a main window and a sub-window that I'd like to present as a modal session. So I'm using this code within the window controller:
self.session = [[NSApplication sharedApplication] beginModalSessionForWindow: self.window];
[[NSApplication sharedApplication] runModalSession: self.session];
However, regardless of where I put this code - in windowDidLoad, in a post-windowDidLoad call from the main window, or even in the window controller's init function - what I get is a modeless sub-window. The sub-window appears over the main window, but the main window continues to respond to input events.
What am I doing wrong?
nvm - found my answer by reading some examples. (Once again, hours of research before posting on Stack failed to yield answers, and I stumble across insight right after posting.)
For posterity, here's the answer: beginModalSessionForWindow doesn't work like runModalForWindow.
With runModal, you can execute that code anywhere, and Cocoa will immediately halt all processing except for the modal window. (Unfortunately, that includes timers tied to non-UI events for background processing.) The code that executes runModal is blocked, and resumes only after the modal window is closed. The system enforces the modality of the window.
beginModalSessionForWindow works very differently. Wherever you execute it, the code starts up the modal window and then keeps executing. In the general use case (as demonstrated in Apple's examples), if you call beginModal before a loop and then condition the loop on polling the status of the session, the loop can perform whatever other processing you want; and during the loop, it's also blocking normal UI events - just like any IBAction would when executing a long-running loop.
The point is that beginModalSession actually doesn't enforce any modality of the window. Rather, your code enforces the modality of the window by executing a long-running loop. If you don't use a loop, but instead just let the "modal" session run and resume the ordinary event loop... then your other windows get all event processing, including UI events. The "modal" window becomes modeless.
I will argue that "beginModalSessionForWindow" should really be called beginModelessSessionForWindow, because that's what it does: it creates a modeless window and returns.
I'm looking for a good way to tell my Cocoa application to quit itself. Rest assured that this will not be used for production code. I'm just looking for an easy way to run one test and then close the application during debugging.
I have found that exit(0); will close the app, but it bypasses all of the normal application exit procedures, and I would like to keep all of them in place.
Essentially I want things to work as if a user pulled "Quit" from the menu, but I want it to happen automatically after I have finished with my test.
My code currently looks like this:
#if (SUPERFANCY_TESTING_MODE)
[self doSomething];
exit(0); // <-- I need something better to go here
#endif
You can pretty much rest assured that your app is going to get killed at least some of the time. Thus, defending against exits the like of exit(0); is required.
However, NSApplication implements the -terminate: method.
[NSApp terminate: nil]; ought to do what you want.
I would generally suggest posting it via -performSelector:afterDelay: with a delay of 0.0 to force it to happen at the top of the next pass through the event loop.
Example:
[NSApp performSelector:#selector(terminate:) withObject:nil afterDelay:0.0];
I really enjoy using RBSplitView, an open source replacement for NSSplitView, but I have a problem in my shipping app and am experiencing it again in a new project.
The problem is I'm telling the RBSplitView to autosave its position state by giving it an autosave name. When my app launches the RBSplitView doesn't seem to honor the saved state till a second after the window is drawn.
I've spent the night trying to debug the behavior but have had little success. Anyone out there use this lib and have some advice?
You can scrub this quicktime movie to the issue at work:
http://media.clickablebliss.com/billable/interface_experiments/rbsplitview_delayed_autosave_reload2.mov
I've still been unable to figure out why this is happening but I do have a workaround.
First, make sure your main window is not visible at launch and then at the end of applicationDidFinishLaunching in your app delegate add something like:
[mainWindow performSelector:#selector(makeKeyAndOrderFront:) withObject:self afterDelay: 0.1];
The delay is the key. If you just tell the window to makeKeyAndOrderFront: I still see the issue. However as long as it has a beat of time it looks good.
This likely is happening because the RBSplitView instance needs to wait until it's first moment to get to set its frame to the autosaved value, which happens to be after the user can see it. This 0.0-delay trick simply delays showing the window until the very next runloop, which gives the split view a chance to do its magic (and other views) so that when the user sees the window, it's already nice and sexy. So just do the delay at 0.0 and you'll be fine.
I have a similar, but slightly different workaround in my app that uses RBSplitView. In applicationDidFinishLaunching:, I call adjustSubviews on the split view before calling makeKeyAndOrderFront: on the window that contains it. This seems to knock the split view in to order before it gets displayed on the screen.