Cocoa: NSTextField and Fullscreen-Mode with enterFullScreenMode: - objective-c

currently I'm experimenting with the enterFullScreenMode: option of NSWindow making a subview of the window's contentView the new fullscreen view which works nice. However, my view contains a NSTextField which behaves weird. When I switch to fullscreen mode it becomes inactive (seems to resign firstResponder status). I can use it just fine by clicking it and by calling
[myField becomeFirstResponder];
which is discouraged by the docs. They say I should always call
[myWindow makeFirstResponder: myField];
which does not work any more after being in fullscreen mode. The weirdest thing however is that when entering something in the field and then exiting the entered text disappears. When switching back fast enough to fullscreen mode it might even be back again. Any idea what I'm doing wrong? Or any feedback on how to make the NSTextField resign firstResponder status in fullscreen mode without being using discouraged API calls?
Thanks in advance,
Nicolas

You mean in 10.6 right?
[myWindow makeFirstResponder: myField];
enterFullScreenMode will make a new window for the view, so myWindow actually is the window before entering fullscreen.
you should use
[[self window] makeFirstResponder: myField];

Related

Cocoa HUD panel shows again after calling orderOut:

I'm using a NSPanel with HUD style to display some information.
There's a button inside the HUD panel, when the user clicks the button, I'll open a new window by calling:
[anotherWindowController showWindow:self];
[anotherWindowController.window makeKeyAndOrderFront];
And I want the panel disappear when the window shows, so I set the delegate of the main window, and in the windowDidResignMain callback, I called [hudPanel orderOut:nil].
The HUD panel did disappear (I can see it), but right after it closed, it reopens.
I've checked all possible orderFront: code, and none of them get called. So my hands are really tied. Is this a system level behaviour? Can anyone guide me through this?
EDIT:
I forgot to mention that, the button resides in a NSPopover. So, basically, there's a NSButton in the HUD panel. When user clicks the button, a NSPopover will show up, inside which, there's the button to bring up the new window.
Big thanks!
I had the problem. The following solved it:
[NSApp endSheet:yourPanel];
[yourPanel orderOut:self];
Use
[hudPanel performClose:nil]
(in Swift I have to use self instead of nil). I had a problem using orderOut with a popover and it was solved by using the above method.
Please add [hudPanel close] after [hudPanel orderOut:nil]
swift: hudPanel.close()
from the apple docs:
If the window is the key or main window, the window object immediately behind it is made key or main in its place. Calling orderOut(_:) causes the window to be removed from the screen, but does not cause it to be released. See the close() method for information on when a window is released.
Sometimes the window reappears during window controller inner logic, I think. I have an issue when long pressing keyboard button kills window, but shot keyDown event only hides it on the split second. After using close all goes smoothly.

NSTextField inside NSPopover is not key until mouse click

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.

NSTextField in status bar doesn't want to receive focus

For some reson sometimes a NSTextField I'm using in Status Bar menu doesn't always allow me to input text. I click it and nothing happens as if it was disabled. Upon restarting program it works again. I don't do anything with it, it's just created in the interface builder.
That's because no NSWindow contains the NSTextField. The NSWindow sets the first responder when the window gets the main window. The NSStatusBar is global. It's never focused so your textfield only will be focused in the very beginning.
I'm not sure if there's a way to solve this problem in a nice way. You might try to set the first responder manually. You could also add a global event monitor
Example:
[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask handler:^(NSEvent* incoming) {
[textfield setStringValue:[incoming characters]];
}];
Note: This is a very bad way to fix this problem. I'd first try to set the NSTextField manually as a first responder if this is possible.

NSTextField is not working over Full Screen

NSTextfield is not working when I make a full screen app.
I have also made first responder of textfield. How can I make it enable and working?
Full Screen window won't get any keyboard events the way it is, due to the fact that it was created with with the NSBorderlessWindowMask style mask. Apparently windows of this type can't become "key windows". However, you can fix this problem by subclassing NSWindow and overriding the canBecomeKeyWindow method.
- (BOOL)canBecomeKeyWindow
{
return YES;
}

IPad dismiss Keyboard without knowing which Textfield opened it

Is there a way to do a general resignFirstResponder to hide the keyboard regardless of what textfield/view/etc calls it?
Reason is I have a lot of textfields on my view and don't want to have to resignFirstResponder for all textfields to hide the keyboard. Just want a general
[self resignFirstResponder].
Any ideas?
Thanks in advance
I know that this has already been marked as answered, but for those that run into this like I did you can just use the following method on the view that contains the textfields.
- (BOOL)endEditing:(BOOL)force
This method looks at the current view and its subview hierarchy for the text field that is currently the first responder. If it finds one, it asks that text field to resign as first responder. If the force parameter is set to YES, the text field is never even asked; it is forced to resign. UIView Documentation
[self.view endEditing:YES];
it will hide keyboard when we click on view.
You can dismiss the keyboard without any reference to UITextfield / UITextView with help of below code:
[[[UIApplication sharedApplication] keyWindow] endEditing:YES];
this will dismiss the keyboard globally without the reference.
hope this will help you.
The easiest way to do this is to have a method for whenever you want to dismiss the keyboard that looks like this:
-(void)dismissKeyboard {
[firstField becomeFirstResponder];
[firstField resignFirstResponder];
}
You can check these questions:
Is it possible to make the iPhone keyboard invisible / remove it without resigning first responder?
Hide Input Keyboard on iPhone Without Knowing First Responder?
In summary:
You can call becomeFirstResponder on some other thing that you choose. It could be a UIViewController or a UIView. I had a similar problem before, I needed to make my keyboard go away when I was pushing my view controller back to its caller, without knowing which textfield was the first responder. Then, on viewWillAppear of my view controller which I was returning back, I called [self becomeFirstResponder] and the keyboard of the pushed view was gone. Because this made whichever text field was it loose being the first responder
In my own app when I had more than one text field and would like to make the keyboard go away regardless which of the fields called it, I would just wrote a method and let each and every of them resignFirstResponder.
I assume that as a programmer, you should have the clear knowledge how many text fields are on your view controller and how you can access them, otherwise it'll get messed up and you app won't look good... :-P