I have an NSView thats used as a status item and I need to run this on/in it:
thingOne = NO;
[self setNeedsDisplay:YES];
but can't figure out how. I tried sending a notification (form another notification a class gets) but the notifications never received. I also tried to add a method to do this but it requires using a + symbol for it and I can't access the classes variables. How can this be done? (If it's even possible)
Thanks for any help
I was able to send the notification to the app delegate. Then I added a method to the view object to change the bool and had the notification call it.
Related
I would like to track each time a certain window appears (becomes visible to the user) in a OS X app. Where would be the most adequate place to call the tracker?
windowWillLoad, maybe?
I expected to find something like windowWillAppear but it seems I'm thinking too much iOS.
How about getting notification such as NSWindowDidBecomeMainNotification, By main I guess the one which is top most on screen directly visible by user.
see : Apple Documentation
Yes, one would expect that a window would notify its delegate or its controller with a windowWillAppear or windowDidAppear message, or post a documented notification like NSWindowDidAppearNotification. But alas, none of those exist. I filed a bug report with Apple and was given the advice to use a storyboard and a view controller instead. This is unhelpful in legacy apps that already use a bunch of window controllers and xibs.
You could subclass NSWindow and override orderWindow:relativeTo: to send a notification. Most, but not quite all, of the messages that make a window show itself ultimately go through this method, including orderBack:, orderFront:, makeKeyAndOrderFront:, and -[NSWindowController showWindow:]. But orderFrontRegardless does not go through orderWindow:relativeTo:, so you would also want to override that for completeness.
Another way to be notified is to make a subclass of NSViewController that controls some view that's always visible in the window. The view controller will receive viewWillAppear and viewDidAppear.
If you're subclassing NSWindow or NSViewController already for some other reason, either of these is a reasonable solution.
If you're not subclassing NSWindow already, and don't have an NSViewController subclass for a view that's always visible in the window, then another way is to use Cocoa bindings to connect the window's visible binding to a property one of your objects. For example, I have a custom NSWindowController subclass. I gave it a windowIsVisible property:
#interface MyWindowController ()
#property (nonatomic) BOOL windowIsVisible;
#end
and I implemented the accessors like this:
- (BOOL)windowIsVisible { return self.window.visible; }
- (void)setWindowIsVisible:(BOOL)windowIsVisible {
NSLog(#"window %# became %s", self.window, windowIsVisible ? "visible" : "hidden");
}
and in awakeFromNib, I bind the window's visible binding to the property like this:
- (void)awakeFromNib {
[super awakeFromNib];
[self.window bind:NSVisibleBinding toObject:self withKeyPath:NSStringFromSelector(#selector(windowIsVisible)) options:nil];
}
When the window becomes visible, the setWindowIsVisible: setter is called with an argument of YES. Note that if the whole app is hidden and reappears, the setter is called again, even though it wasn't called with argument NO when the app was hidden. So be careful not to assume the window was previously hidden.
Also, the binding might create a retain cycle, so you should probably unbind it when the window is closed, unless you want to keep the window and controller around. Note that the window does post NSWindowWillCloseNotification when it's closing, so you don't need any special magic to detect that.
I'm trying to create a complex custom NSControl that must be able to send more than one message.
For example, on mouse over in must send an action, and on mouse drag in must send another action.
I can't understand how to wire a target to a control and make the control sends whatever message to the target.
In my opinion i have to follow these steps:
Instantiate the NSControl i.e. myControl
set the Target action for myControl for every actions (I don't know how to do that!)
The myControl instance will send action with [NSApp sendAction: [self action] to: [self target] from: self]
Can you help me on step 2? and confirm my steps?
You need Delegation pattern. Standard Cocoa controls send at most one action, and use delegation for anything additional. IB does not support setting more than one action, so you can't solve step 2.
If delegate is an outlet, you can set it right from IB whenever the delegate is file's owner or also instantiated in this nib, like you would do that for e.g. NSWindow or NSTableView.
I'm still picking up ObjC and I'm just trying to make sure I understand the concept of NSNotifications fully:
The [NSNotificationCenter defaultCenter] is a stationary object which is not the sender or the receiver. It merely routes an NSNotification, but in no way, shape, or form handles the event (by default).
Is that correct?
Theory:
Would that allow an AppDelegate to push a notification to the defaultCenter and have something further on in the responder chain / display list (e.g., UITableViewCell) pick up on the action?
Exactly. NSNotificationCenter is just the clearinghouse for the notifications. It keeps track of all the objects observing each notification, so that when a notification is posted, it can be routed to all the right observers.
And yeah, no reason why your AppDelegate can't post a notification that gets picked up by things like a UITableViewCell. NSNotifications are great for situations where an object has to send data to other objects, or tell them that something happened, and you won't know what the recipients should be until runtime.
I have the following code in a Cocoa application:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSArray* arrayAppList = [[NSWorkspace sharedWorkspace] runningApplications];
}
My intention is to use KVO to detect an application when changes its state between inactive to active.
I read that I have to use the instance method -addObserver:forKeyPath:options:context:
And then use -observeValueForKeyPath:ofObject:change:context: to respond to change notifications.
I understand that -observeValueForKeyPath is a callback method where I can write code to respond to the properties changes I am interested in.
Nevertheless, I feel confused in how I must to use the addObserver method in order to be notified when the active property of the runningApplications change. Now, I am wondering where is the place to make the registration, for now I am using -applicationDidFinishLaunching but not sure if is the right place to do it. Additionally if I use the -observeValueForKeyPath callback method, I have to implement it in the class that inherits from NSObject and is the same class where I am registering the notification?
You should call the addObserver:… method on each object in the runningApplications array (using isActive as the key path).
Starting the observing after your app finishes launching sounds about right. Time-wise, that is. As for the place, there should be a separate class dedicated to these observations. By implementing the observation code right in the app delegate you would violate the single-responsibility principle (and that means headache in the long term).
The observeValueForKeyPath:… callback should be implemented by the object that called the addObserver:… methods.
I am trying to update another windows when the one becomes visible. So I found the NSWindowDidExposeNotification and tried to work with it, so I wrote in my awakeFromNib:
// MyClass.m
- (void)awakeFromNib {
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:#selector(mentionsWindowDidExpose:)
name:NSWindowDidExposeNotification
object:nil];
}
and implemented the method
// MyClass.h
- (void)mentionsWindowDidExpose:(id)sender;
// MyClass.m
- (void)mentionsWindowDidExpose:(id)sender {
NSLog(#"test");
}
But it never gets called which is odd. What do I do wrong here?
Generally speaking, you would set up your controller as the window's delegate in order to receive these notifications, like so:
// MyClass.m
- (void)awakeFromNib {
// note: this step can also be done in IB by dragging a connection
// from the window's "delegate" property to your `MyClass` object
[window setDelegate:self];
}
- (void)windowDidExpose:(NSNotification *)notification {
NSLog(#"test");
}
Although, after reading here and here, windowDidExpose may not be your best bet. I would recommend trying the windowDidBecomeKey delegate method instead. That one is posted whenever your window gains "focus" (starts responding to user input) which may be the right time to show your second window.
Update: (in response to comments)
Apple's documentation (quoted below) indicates that NSWindowDidExposeNotification is only valid for nonretained windows, which, according to the posts that I linked above, are quite uncommon.
NSWindowDidExposeNotification
Posted whenever a portion of a nonretained NSWindow object is exposed, whether by being ordered in front of other windows or by other windows being removed from in front of it.
The notification object is the NSWindow object that has been exposed. The userInfo dictionary contains ... the rectangle that has been exposed.
On a higher level, NSNotification objects are simply packages of data that get passed around between Cocoa classes and NSNotificationCenter objects. NSNotificationCenter objects are controllers that manage these packages of data and send them out to observers as required. There is usually no need to trap notifications directly. You can simply use KVC/KVO or pre-defined delegates in your classes and Cocoa handles all of the dirty details behind the scenes.
See Notification Programming Topics and Key Value Coding Programming Guide if you want to know more.