I am attempting to set the key equivalent of a NSButton in a NSWindow. I am using the following code in my view controller's class:
someButton.keyEquivalent = "\r"
However, when I run the application, pressing the key will not perform the button's action but play the system funk sound.
The window which contains this NSButton is presented as a window (not a sheet) using a modal NSStoryboardSegue. If I use the same code and configuration in my initial window, the key equivalent performs correctly. Would the type of presentation cause this problem? Thanks.
EDIT
Turns out this may be a possible bug. Key equivalents will not work when a title bar is deselected in the IB. I am now attempting to find a way to keep this selected with the same window appearance. Keeping the option selected and using the titlebarAppearsTransparent property on NSWindow, I have successfully removed the title bar but now I am unsure how to remove the window border. Any ideas?
Do you happen to have the title bar disabled in your window? There's some unexpected behavior (hesitate to call it a bug) where keyboard events are ignored in a modal window if the title bar is disabled (even though the title bar isn't used in sheets).
Related
I am new to Xcode/OSX UI so there is probably something silly I'm overlooking. This is XCode 5.11 targeting OSX 10.10 desktop.
I have inherited some code with a few views where navigating among child controls within the view using the tab key does not work.
In researching this almost everything says to be sure to set the first responder and then chain your controls using nextKeyView.
I followed the steps in this video https://www.youtube.com/watch?v=SRrE8eqp0dU (XCode 4, but all the functionality seemed to be the same for 5.11) to no avail.
I also had a look at this solution How to make child controls of view will get focus on Tab and Shift+Tab in NSViewController which sounds like a similar issue to what I am seeing, but one of the classes I inherited uses NSWindowController vs. NSViewController as the base and there is no loadView to override and the other which did derive from NSViewController did not behave any differently with the changes made to loadView.
When my window launches my first responder control (NSTextField in this case) has focus (blue highlight) but tab key is ignored and focus will not change unless I use the mouse.
So it's really not a tab ordering issue initially, it seems like a tab ignored issue and who knows what the ordering is. I tried setting focus to a NSButtonCell and NSPopUpButton using the mouse and then tab navigate from those to see if there was some issue with my NSTextField but they exhibit the same behavior. None of the controls are set to "Refuses First Responder" which was another setting it was recommended to check.
I'm at a loss and looking for any other things to try or check.
The first view I am having an issue with is: Window / Child View / Multiple Child Boxes / Multiple controls per box in case that matters or complicates things. It is basically for setting application Preferences.
The second view seems like it may be more complicated in that there is a single Window that swaps out its child view in a next/back progression (wizard interface). The initial window nib is "blank" so I didn't see how to associate a first responder from IB like I did with the Preferences window since all the controls are on their own individual view nibs (these all show as "Custom View" vs. just "View" for Preferences).
The resolution for me was to ensure that the "Auto Recalculates View Loop" setting in the Attributes Inspector was enabled for the windows hosting these views. This corresponds to the autorecalculatesKeyViewLoop property of NSWindow.
Inside my .xib, I've placed an NSColorWell inside an NSView, and connected an IBAction in the controller to the NSColorWell's Sent Actions (via File's Owner). I figured I would respond to a click in my controller and send activate to bring up the NSColorPanel.
But unlike other my controls, I'm not getting the IBAction called. Clicking invokes a drag action on the color. I noticed this control doesn't derive from NSActionCell (like all my other controls). What's the proper control that is supposed to be used to both display a color and invoke the NSColorWell when clicked?
(note: this is Xcode/IB 3.2.x)
You listed both osx and ios in the tags, but I'm guessing this is an OS X problem.
There is a "Bordered" checkbox in IB's Attributes Inspector for NSColorWell. This toggles between a button-style color well, which is what you're asking for, and a color well which you can only drag a color swatch from. Make sure that's checked and you'll get the action like you're expecting.
I am trying to tidy up my UI by consolidating various things in a Tool Bar, and am utterly confused. I am using Interface Builder rather than constructing the controls programmatically, because my UI is fairly simple and not particularly dynamic.
What I did did so far:
Added an empty tool bar.
Dragged two previously existing and working buttons onto the tool bar. They changed their class from UIButton
to UIBarButtonItem, and the inspector now shows them as having no
Sent Actions or Referencing Outlet, but the the previous action &
outlet in the View Controller - responding to taps, setting the
label of the button - still work.
Created a new Button directly
in the tool bar. Wired up its action & outlet by ctrl-drag in the
normal way. The inspector shows the Action and Outlet for this
button as connected, which is nice, but sadly neither of them works.
Clicking the button does not invoke the action; setting the label of
the button does not cause anything to happen on the screen, even
after I tried prodding the tool bar with a setNeedsDisplay.
I'm not sure what to try next. Googling has shown me that I'm not the only person to find using UIToolBar via Interface Bulder difficult and confusing, but I haven't found a solution to my exact problem.
I don't particularly want to resort to creating my entire GUI programmatically just to tidy up a few buttons. Creating all the controls in Interface Builder outside the tool bar, getting them wired up and working, then moving them into the tool bar would presumably also work - but it would be a kludge, and would leave me still none the wiser if anything went wrong later.
Should you try using UIBarButtonItem instead of UIButton? It works for me.
i had a similar issue.
Did you created an extra UITapGestureRecognizer for root view ?
Maybe for something like > When elsewhere than UITextView clicked, resignFirstResponder for all UITextViews !
In my case, on 7.1, that extra UITapGestureRecognizer prevented transfer of event to IBAction of UIBarButtonItem which is inside an UIToolBar.
IBAction was made on Storyboard by Ctrl+Drag.
on 8.1 it was working. Not on 7.1
Read some suggestions to create an extra UIView and putting all visual elements into that extra UIView except UIToolBar
I have a transparent NSWindow that follows the user's screen everywhere he goes (the NSWindowstays in front of every app, no matter what, even fullscreen apps).
In that NSWindow i have a mouseDown event that shows a popup. Let's say i'm on safari in fullscreen mode and i have my Window in front of it, i click on safari and i click again on my Window: nothing happens, the mouseDown doesn't occur. I have to click again so the mouseDown event is triggered.
How can i force my NSWindow to be always active so i don't have to click it 2x to trigger the mouseDown when i click on a background app and click in my window again?
Thank you!
I'm not sure if this is exactly what you want (it's not quite a window wide setting), but, from the documentation:
By default, a mouse-down event in a window that isn’t the key window
simply brings the window forward and makes it key; the event isn’t
sent to the NSView object over which the mouse click occurs. The
NSView can claim an initial mouse-down event, however, by overriding
acceptsFirstMouse: to return YES.
The argument of this method is the
mouse-down event that occurred in the non-key window, which the view
object can examine to determine whether it wants to receive the mouse
event and potentially become first responder. You want the default
behavior of this method in, for example, a control that affects the
selected object in a window.
However, in certain cases it’s
appropriate to override this behavior, such as for controls that
should receive mouseDown: messages even when the window is inactive.
Examples of controls that support this click-through behavior are the
title-bar buttons of a window.
Or you could try fiddling with
- (void)sendEvent:(NSEvent *)theEvent
and see if you can handle events in a custom way.
If you add a borderless NSButton instance to your window's view and set your image as the button's image (and as its alternate image, to make it more beautiful), it will work out of the box: Just connect the button's action method to your app delegate (or the object where you want to process the click action). A click on the image (i.e. the button) will then trigger the button's action method, no matter which window is active.
This worked for me, hope that will be helpful, This will keep your window always on Top of all applications
[self.window makeKeyAndOrderFront:nil];
[self.window setLevel:NSStatusWindowLevel];
I think what you really should do is use an NSPanel (a floating palette -- a special kind of NSWindow) that will do exactly what you want in a way that's consistent with the OS rather than trying to fight intended behavior.
Here's the NSPanel documentation:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nspanel_Class/Reference/Reference.html
And here's some helpful and pithy information:
http://cocoadev.com/wiki/NSPanel
By default, an NSPanel will disappear when the application is inactive, but you can turn this off.
I apologize for not laying it out more fully ... pressed for time.
Edit:
Note that you can probably get your window to behave as desired simply:
"The NSView can claim an initial mouse-down event, however, by overriding acceptsFirstMouse: to return YES."
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html
You'll need to do this with any NSView subclass to skip the "activation click".
I want to run a simple dialog similar to Finder Go To Folder.
I have used a NSPanel made this Document Modal and run with runModal.
This works, but displays a title.
If I turn off the Title Bar (in IB) the buttons work, but the NSTextField does not get keyboard focus.
I have tried lots of techniques to make it firstResponder or set as key, setBecomesKeyOnlyIfNeeded:NO but to no avail.
You need to subclass NSWindow, override - (BOOL)canBecomeKeyWindow and return YES.
By default, borderless windows cannot become the key window.