So I thought I had covered my bases, but apparently I'm missing a key step or two.
I have an NSPanel that is displayed (makeKeyAndOrderFront:) when an NSStatusItem is pressed. Things work great, but as the NSPanel displays a title bar, the panel is also draggable. (This is undesired.)
The first screenshot shows the panel with "Title Bar" enabled in Interface Builder, in the Appearance category. (Sorry for the blur, things are still under lock and key for now.)
The only change that is made in Interface Builder is unchecking the "Title Bar" checkbox. I then save and re-run, and that's what you see in the second screenshot. While a slight shadow appears, the panel does not.
Things I've tried:
I've subclassed the NSPanel and returned YES for canBecomeKeyWindow and canBecomeMainWindow after a bit of research, but (prior to subclassing) these methods both returned NO regardless of whether I was using a Title Bar or not. So I don't think this is the issue.
I've ensured that the frame for the NSPanel is properly set. It has a good height, and the origin is set properly as well.
Edit: Forgot to Mention:
The application is a menu-bar-only application. In the screenshot below, note that an additional entry was added to Info.plist to enforce this.
I've had problems with this in the past. I was able to resolve it by first "ignoring" other apps, then making it the key window. Give it a shot and see if it works for you.
[NSApp activateIgnoringOtherApps:YES];
[[self window]makeKeyAndOrderFront:self];
Also, try setting the window level to NSPopUpMenuWindowLevel during initialization.
[[self window]setLevel:NSPopUpMenuWindowLevel];
I have also had problems with the way that nib files are loaded on Mac OS X. They're loaded "lazily", which means that they won't be initialized until they're needed. This causes a problem when you're wanting to set specifics on the window, but you can't because awakeFromNib doesn't seem to be called, due to lazy nib loading. To fix this, here's what I've done in the past. In your delegate (or wherever you initialize your window), kick the window into action by accessing the window property on the initialized class:
wc = [[blah alloc]initWithWindowNibName:NSStringFromClass([blah class])];
(void)[wc window]; //just kicks the lazy nib loading into gear
By doing so, you're forcing the nib to initialize. That way, when the user clicks the menubar icon the nib is already initialized, and awakeFromNib has already been called.
While a slight shadow appears, the panel does not.
Are you saying makeKeyAndOrderFront: on this NSPanel object doesn't display it when running your app? I just created a sample project, NSButton triggers the same type of NSPanel to display, and it works fine.. titleBar enabled or not.
http://cl.ly/3d0U3C0P3u2D0m3T1w1N
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.
I have an application that needs to display a window on top of anythings else. To achieve this I call [window setLevel:NSStatusWindowLevel] on my main window.
This works fine except that I can't use any modal dialogs or alerts from this window. The problem seems to be that [NSWindow beginSheet...] internally calls setLevel: on the target modal window with a value lower than NSStatusWindowLevel, so the modal dialog is displayed behind its parent window. The same happens when using an NSAlert from a window with higher window level, the alert is displayed behind.
The only [ugly] workaround I found is to inherit NSWindow, override setLevel: and prevent setting a lower level value on these modal windows but this only works when I have control over the window and doesn't work for NSAlerts.
Is there a more elegant solution for displaying modal dialogs from a NSWindow with high window level value that will also work with NSAlerts? Or I will be unable to use NSAlert with this approach?
one thing that comes to mind is to check if NSAlert uses a special NSWindow subclass you could make a category on it and hook the setLevel: method via swizzling (here is an example of extending an existing method via swizzling). there is nothing stopping you from doing this in a plain NSWindow subclass either.
I know its not the "elegant solution" you'd hoped for, but its the only one I know off the top of my head. I suppose it is slightly more elegant in that you don't have to insert your custom subclass everywhere throughout your program, but less elegant in that you are messing with the objective-c runtime using code that simply seems wrong.
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've got an NSPopover that is shown from interaction with an NSStatusItem. I've blogged about the hacks I needed to do to make input even possible in this situation here: http://blog.brokenrobotllc.com/using-nspopover-with-nsstatusitem
I have an NSTextField inside the NSPopover's content view. When I open the NSPopover, the NSTextField appears as if it is key (the cursor blinks). But, when typing, nothing shows up. If I click the mouse in the field, my input starts showing up there.
I've tried things like invoking NSWindow's makeFirstResponder upon popoverDidShow:. There was no change in behavior from this. Anyone have any ideas here?
My guess is you need to make your app active; try calling
[NSApp activateIgnoringOtherApps:YES];
when you show your popover.
Edit: Of course, I could be wrong. This is all just off the top of my head.
Is there a way to check if a NSWindow is visible or not? I want to display a sheet controller once the first window of my app became visible (the animation on 10.7 ended and the user can see the window!). If I just show the sheet in windowDidLoad, it results in a stupid looking animation (sheet rolling out, window popping out from the back). I know that NSWindowDelegate provides two methods which are invoked when a window either became the key window or the main window, however, this doesn't have to mean that the window is already fully visible at the time. This is even more noticeable on Lion where windows tend to pop up with this stupid animation.
I would go for something like this:
if ([myWindow isVisible]) {
// Do stuff
}
Or an an observer for this key path to be notified when the change occurs.
For what it's worth, you can also bind to the window.visible property. Xcode 4 may squawk at you, saying it's not a bindable property, but it will work.
This can be useful if you are trying enable/disable show/hide NSStatusItem based on whether the window is visible, as well as other approaches.
i.e. in Interface Builder:
Bind to: App Delegate
Model Key Path: self.window.visible