I have a NSMenu with dynamically added NSMenuItems. The NSMenu is not refreshing properly while it's kept open. I am calling NSMenu update method in NSEventTrackingRunLoopModes.
I have implemented following methods to update NSMenu.
- (void)menuNeedsUpdate:(NSMenu *)menu {
for (NSInteger index = 0; index < count; index++)
[self menu:menu updateItem:[menu itemAtIndex:index]
atIndex:index
shouldCancel:NO];
}
- (BOOL)menu:(NSMenu *)menu updateItem:(NSMenuItem *)item atIndex:(NSInteger)index shouldCancel:(BOOL)shouldCancel`
- (NSInteger)numberOfItemsInMenu:(NSMenu *)menu
Updating the menu items in NSEventTrackingRunLoopMode solved this issue.
I am dynamically populating menu items in a timer and NSMenu is not updating while it's open.
Make sure to have the timer fire on the respective run mode:
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
You might only have it fire on NSDefaultRunLoopMode right now.
You have left out a bunch of the code. However, you aren't supposed to call -menu:updateItem:atIndex:shouldCancel:. That's a method that you're supposed to implement and the framework is supposed to call it.
Also, generally you're only suppose to implement either -menuNeedsUpdate: or both of -numberOfItemsInMenu: and -menu:updateItem:atIndex:shouldCancel:. Implementing all three doesn't make much sense. You implement the former if you can build the menu immediately. You implement the latter two if building the menu will take some time.
Finally, all of those methods are documented as being called "when a menu is about to be displayed". I'm not terribly surprised that they're not called repeatedly while the menu is open.
If you know the menu needs to be updated, you can try invoking -[NSMenu update]. That may provoke it to call your delegate methods. I'm pretty sure you can also just call the methods on NSMenu and NSMenuItem to modify the menu, without waiting for your delegate to be called.
Related
I have a relatively-lengthy task. So I bring up a separate window (NSWindowController) from AppDelegate to show progress. It goes like
//AppDelegate.m
if (self.progresswindow == nil) {
self.progresswindow = [[ProgressController alloc] initWithWindowNibName:#"ProgressController"];
}
[progresswindow showWindow:self];
//[[progresswindow window] setReleasedWhenClosed:NO];
[NSApp runModalForWindow:progresswindow.window];
When a task is complete, the progress window will close itself.
//ProgressController.m
[NSApp stopModal];
[self close];
It works fine. But when I click on a button to start another session of a task with the same window, the application won't run a task although it opens. It appears that the last instance hasn't be released. The progress window has the following lines.
- (void)windowDidLoad {
NSLog(#"Hey!");
}
And NSLog won't be called for the 2nd time. I wonder what I'm doing wrong? Calling setReleasedWhenClosed from AppDelegate has no effect. I have the Release When Closed checkbox enabled, anyway. I read something like I need to observe NSWindowWillCloseNotification the progress window in a different topic so that I can release it when it closes. But I'm using ARC. So I can't manually release it, can I? Meanwhile, if I open Apple's sample (TableViewPlayground), it seems that they use this notification. Furthermore, I've read this topic and this topic. But I don't know what the problem is.
I appreciate any advice. Thank you for your time.
Release the Progress-Window-Controller.
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];
}
Using Cocoa with latest SDK on OSX 10.6.6
I have an NSToolbar with custom toolbar items and also the built in fonts and colors NSToolbarItem items (NSToolbarShowFontsItem and NSToolbarShowColorsItem identifiers).
I need to be able to enable/disable those in various situations. Problem is validateToolbarItem: is never called for these items (it is being called for my other toolbar items).
The documentation is not very clear about this:
The toolbar automatically takes care
of darkening an image item when it is
clicked and fading it when it is
disabled. All your code has to do is
validate the item. If an image item
has a valid target/action pair, then
the toolbar will call
NSToolbarItemValidation’s
validateToolbarItem: on target if the
target implements it; otherwise the
item is enabled by default.
I don't explicitly set target/action for these two toolbar items, I want to use their default behavior. Does it mean I can't validate these items? Or is there any other way I can do this?
Thanks.
After some trial and error, I think I was able to figure this out and find a reasonable workaround. I will post a quick answer here for future reference for others facing the same problem.
This is just one more of Cocoa's design flaws. NSToolbar has a hardcoded behavior to set the target/action for NSToolbarShowFontsItem and NSToolbarShowColorsItem to NSApplication so as the documentation hints it will never invoke validateToolbarItem: for these NSToolbarItem items.
If you need those toolbar items validated, the trivial thing to do is not to use the default fonts/colors toolbar items but to roll your own, calling the same NSApplication actions (see below).
If using the default ones, it is possible to redirect the target/action of them to your object and then invoke the original actions
- (void) toolbarWillAddItem:(NSNotification *)notification {
NSToolbarItem *addedItem = [[notification userInfo] objectForKey: #"item"];
if([[addedItem itemIdentifier] isEqual: NSToolbarShowFontsItemIdentifier]) {
[addedItem setTarget:self];
[addedItem setAction:#selector(toolbarOpenFontPanel:)];
} else if ([[addedItem itemIdentifier] isEqual: NSToolbarShowColorsItemIdentifier]) {
[addedItem setTarget:self];
[addedItem setAction:#selector(toolbarOpenColorPanel:)];
}
}
Now validateToolbarItem: will be called:
- (BOOL)validateToolbarItem:(NSToolbarItem *)theItem {
//validate item here
}
And here are the actions that will be invoked:
-(IBAction)toolbarOpenFontPanel:(id)sender {
[NSApp orderFrontFontPanel:sender];
}
-(IBAction)toolbarOpenColorPanel:(id)sender {
[NSApp orderFrontColorPanel:sender];
}
I guess the engineers who designed this never thought one would want to validate fonts/colors toolbar items. Go figure.
I've got a statusbar item that pops open an NSMenu, and I have a delegate set and it's hooked up correctly (-(void)menuNeedsUpdate:(NSMenu *)menu works fine). That said, that method is setup to be called before the menu is displayed, I need to listen for that and trigger an asynchronous request, later updating the menu while it is open, and I can't figure out how that's supposed to be done.
Thanks :)
EDIT
Ok, I'm now here:
When you click on the menu item (in the status bar), a selector is called that runs an NSTask. I use the notification center to listen for when that task is finished, and write:
[[NSRunLoop currentRunLoop] performSelector:#selector(updateTheMenu:) target:self argument:statusBarMenu order:0 modes:[NSArray arrayWithObject:NSEventTrackingRunLoopMode]];
and have:
- (void)updateTheMenu:(NSMenu*)menu {
NSMenuItem *mitm = [[NSMenuItem alloc] init];
[mitm setEnabled:NO];
[mitm setTitle:#"Bananas"];
[mitm setIndentationLevel:2];
[menu insertItem:mitm atIndex:2];
[mitm release];
}
This method is definitely called because if I click out of the menu and immediately back onto it, I get an updated menu with this information in it. The problem is that it's not updating -while the menu is open-.
Menu mouse tracking is done in a special run loop mode (NSEventTrackingRunLoopMode). In order to modify the menu, you need to dispatch a message so that it will be processed in the event tracking mode. The easiest way to do this is to use this method of NSRunLoop:
[[NSRunLoop currentRunLoop] performSelector:#selector(updateTheMenu:) target:self argument:yourMenu order:0 modes:[NSArray arrayWithObject:NSEventTrackingRunLoopMode]]
You can also specify the mode as NSRunLoopCommonModes and the message will be sent during any of the common run loop modes, including NSEventTrackingRunLoopMode.
Your update method would then do something like this:
- (void)updateTheMenu:(NSMenu*)menu
{
[menu addItemWithTitle:#"Foobar" action:NULL keyEquivalent:#""];
[menu update];
}
(If you want to change the layout of the menu, similar to how the Airport menu shows more info when you option click it, then keep reading. If you want to do something entirely different, then this answer may not be as relevant as you'd like.)
The key is -[NSMenuItem setAlternate:]. For an example, let's say we're going to build an NSMenu that has a Do something... action in it. You'd code that up as something like:
NSMenu * m = [[NSMenu alloc] init];
NSMenuItem * doSomethingPrompt = [m addItemWithTitle:#"Do something..." action:#selector(doSomethingPrompt:) keyEquivalent:#"d"];
[doSomethingPrompt setTarget:self];
[doSomethingPrompt setKeyEquivalentModifierMask:NSShiftKeyMask];
NSMenuItem * doSomething = [m addItemWithTitle:#"Do something" action:#selector(doSomething:) keyEquivalent:#"d"];
[doSomething setTarget:self];
[doSomething setKeyEquivalentModifierMask:(NSShiftKeyMask | NSAlternateKeyMask)];
[doSomething setAlternate:YES];
//do something with m
Now, you'd think that that would create a menu with two items in it: "Do something..." and "Do something", and you'd be partly right. Because we set the second menu item to be an alternate, and because both menu items have the same key equivalent (but different modifier masks), then only the first one (ie, the one that is by default setAlternate:NO) will show. Then when you have the menu open, if you press the modifier mask that represents the second one (ie, the option key), then the menu item will transform in real time from the first menu item to the second.
This, for example, is how the Apple menu works. If you click once on it, you'll see a few options with ellipses after them, such as "Restart..." and "Shutdown...". The HIG specifies that if there's an ellipsis, it means that the system will prompt the user for confirmation before executing the action. However, if you press the option key (with the menu still open), you'll notice they change to "Restart" and "Shutdown". The ellipses go away, which means that if you select them while the option key is pressed down, they will execute immediately without prompting the user for confirmation.
The same general functionality holds true for the menus in status items. You can have the expanded information be "alternate" items to the regular info that only shows up with the option key is pressed. Once you understand the basic principle, it's actually quite easy to implement without a whole lot of trickery.
The problem here is that you need your callback to get triggered even in menu tracking mode.
For example, -[NSTask waitUntilExit] "polls the current run loop using NSDefaultRunLoopMode until the task completes". This means that it won't get run until after the menu closes. At that point, scheduling updateTheMenu to run on NSCommonRunLoopMode doesn't help—it can't go back in time, after all. I believe that NSNotificationCenter observers also only trigger in NSDefaultRunLoopMode.
If you can find some way to schedule a callback that gets run even in the menu tracking mode, you're set; you can just call updateTheMenu directly from that callback.
- (void)updateTheMenu {
static BOOL flip = NO;
NSMenu *filemenu = [[[NSApp mainMenu] itemAtIndex:1] submenu];
if (flip) {
[filemenu removeItemAtIndex:[filemenu numberOfItems] - 1];
} else {
[filemenu addItemWithTitle:#"Now you see me" action:nil keyEquivalent:#""];
}
flip = !flip;
}
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSTimer *timer = [NSTimer timerWithTimeInterval:0.5
target:self
selector:#selector(updateTheMenu)
userInfo:nil
repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
}
Run this and hold down the File menu, and you'll see the extra menu item appears and disappears every half second. Obviously "every half second" isn't what you're looking for, and NSTimer doesn't understand "when my background task is finished". But there may be some equally simple mechanism that you can use.
If not, you can build it yourself out of one of the NSPort subclasses—e.g., create an NSMessagePort and have your NSTask write to that when it's done.
The only case you're really going to need to explicitly schedule updateTheMenu the way Rob Keniger described above is if you're trying to call it from outside of the run loop. For example, you could spawn a thread that fires off a child process and calls waitpid (which blocks until the process is done), then that thread would have to call performSelector:target:argument:order:modes: instead of calling updateTheMenu directly.
[Cocoa/Objective-C]
I adapted a timer routine (for current time) from this site (and it works great - thanks). It's currently attached to a button.
My question is: How do I make it start when my app starts up (and not use a button) (in other languages, I'd simply put the action listener or timer in the Form)...?
Thank for any help on this!
In your application delegate you'll find a method called
- (void)applicationDidFinishLaunching:(UIApplication *)application
I guess that would be where to start a timer on app startup.
Put it in your awakeFromNib method. This is called on all objects that get deserialized from your nib (like your application delegate), but it isn't called until all objects are deserialized and wired (so you can use your text field, for instance). For example:
- (void)timerFired:(NSTimer*)timer
{
NSLog(#"Timer completed!");
}
- (void)awakeFromNib
{
[NSTimer scheduledTimerWithTimeInterval:30.0 target:self selector:#selector(timerFired:) userInfo:nil repeats:NO];
}
Obviously, in this simple example the timer could have been created in either the applicationDidFinishLaunching: method or the awakeFromNib method since it doesn't interact with any other serialized objects, but in your case, it sounds like you need the awakeFromNib method.