I have a custom NSView within a NSMenuItem (attached to a MenuBar) that respond to a mouseDown event. But I need to click twice on the custom view for the mouseDown function to be called, this is because the custom view should be first responder. And when I override the method acceptsFirstResponder in my CustomView Controller as indicated by the Cocoa Event Handling Guide, it does not work. What is the solution? Is it doable?
Override the NSView method acceptsFirstMouse: to return YES for the event in question. If you only want to accept the first mouse click for some types of events, you can do that by examining the event parameter passed in. Unless there is something special about the NSMenuItem case in particular, this should be what you want; it's the standard Cocoa mechanism for this. Note that this method is not the same as the acceptsFirstResponder method you have tried. See Apple's doc for details.
For reference I have just added to my custom view the following:
- (BOOL)acceptsFirstMouse:(NSEvent *)theEvent {
return YES;
}
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 adding a toolbar programmatically inside an interface inheriting NSObject <NSToolbarDelegate>, and implementing these methods:
- (NSToolbarItem*)toolbar:(NSToolbar*)toolbar itemForItemIdentifier:(NSString *)itemIdentifier willBeInsertedIntoToolbar:(BOOL)willBeInsertedIntoToolbar;
- (NSArray *)toolbarSelectableItemIdentifiers: (NSToolbar*)toolbar
- (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar *)toolbar
- (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar
I also add a button by calling setView on a NSToolbarItem. This view contains an NSButton and is in the .XIB interface.
However, setAction on the same item does not work, due to reason described at http://www.cocoabuilder.com/archive/cocoa/291782-nstoolbaritem-custom-view-setaction.html#291783.
How do I implement this solution?
You could set the target and action of the NSButton in the nib file itself, or if you need to do it programmatically, then create an IBOutlet to the NSButton and do it in code.
When you use an NSButton in a toolbar item, it effectively acts like an NSButton would anywhere else in your interface, rather than as an NSToolbarItem per se. For example, you won't be able to easily disable or enable the button through the use of the standard -validateToolbarItem: or -validateUserInterfaceItem:; rather, you'll need to have an IBOutlet to the button in question, or otherwise use bindings to enable or disable the button.
I have an NSView which covers its parent window's content view. This view has a click event handler which removes it from the content view. Inside this view, I have another view. When I drag the mouse in this inner view, the mouse events are applied not only to the view in the front, but also to the views behind. Additionally, the cursors from the views behind are showing up as well. This is the same problem occurring here: NSView overlay passes mouse events to underlying subviews? but the answer there won't work for my project because I can't open another window.
Without seeing your event-handling code it's difficult to know what's happening, but I suspect you might be calling super's implementation of the various event-handling methods in your implementations.
NSView is a subclass of NSResponder, so by default un-handled events are passed up the responder chain. The superview of a view is the next object in the responder chain, so if you call, for example, [super mouseDown:event] in your implementation of ‑mouseDown:, the event will be passed to the superview.
The fix is to ensure you don't call super's implementation in your event handlers.
This is incorrect:
- (void)mouseDown:(NSEvent*)anEvent
{
//do something
[super mouseDown:event];
}
This is correct:
- (void)mouseDown:(NSEvent*)anEvent
{
//do something
}
Rob's answer and Maz's comment on that answer solve this issue, but just to make it absolutely explicit. In order to prevent a NSView from bleeding it's mouse events to the parent, one must implement the empty methods.
// NSResponder =========================================
- (void) mouseDown:(NSEvent*)event {}
- (void) mouseDragged:(NSEvent*)event {}
- (void) mouseUp:(NSEvent*)event {}
Is there a way to get notified when a NSTextView gets modified?. In a NSTextField I just set the target for the default sent action and works perfectly, but I don't see any sent actions on a NSTextView.
NSTextView inherits from NSText, which conforms to the NSTextDelegate protocol. Look it up in the docs. The method you are looking for is: - (void)textDidChange:(NSNotification *)aNotification which you can either implement in your TextView's delegate or get by registering for a "NSTextDidChangeNotification" notification.
Subclass NSTextField and override the textDidChange method that it has.
The delegate will tell you when it will start editing and when it will finish editing. But the control itself gets the textDidChange method called on itself.
Subclass it and override the method
- (void)textDidChange:(NSNotification *)notification;
then you could set a flag that you can access externally.
How would I be able to run an IBAction based on another event? For example I could use a piece of code to run an IBAction.
What I'm trying to do is have two different buttons run one or more IBActions.
You can hook multiple buttons up to the same IBAction, so you could do it that way.
But IBActions are just methods. For example, if you have some action doSomething:, you can just call it on an object:
[obj doSomething:nil];
An IBAction is just a hint for the Interface Builder. It's actually another way of saying void.
#define IBAction void
So there is nothing special about it.
In Interface Builder, you can connect touch event for different buttons to the same IBAction.
You can also call IBAction methods from another IBAction method. Use the sender argument to identify the source of the event.
For example,
-(IBAction)buttonTapped:(id)sender {
UIButton *btn = (UIButton *)sender;
NSLog(#"tapped: %#", btn.titleLabel.text);
[self anotherIBAction:sender];
}