I have a view in XIB where i used several text fields in it. Let say the first text field becomes first responder as soon as the view gets loaded in the window. If i press tab key in my machine's keyboard to navigate to next text field ;apart from the immediate text field, all other text fields are also becomes first responder and the textfield begin editing delegate menthod gets called for all the text fields. What could be the issue ? This will occur not only in simulator when we use machine's keyboard also when we use bluetooth keyboard for a iOS device.
Pressing of tab key => navigation to next textfield with respect to heirarchy of the textfields in the view.
When u press tab - textfieldshouldbeginediting will be called as many times as you textfields - meaning - 5 textfields => one tab key press, all the 5 instances will be called.
When you press tab - textfielddidbeginediting will be called only once with respect to the new textfield's instance - Hence any logic for the textfield is better to be in textfielddidbeginediting delegate method.
These are the default characteristics of the delegate methods and not an issue.
Related
When I bind "File > Save ⌘S" to a custom IBAction it works fine, except when I use the window's field editor to make something editable programmatically. (NSTableHeaderCells, specifically.)
When the cursor is in any NSTextField, ⌘S is still activated. That's what I want.
When the cursor is in the field editor (NSText based), ⌘S is deactivated. This only happens when I change the connection in MainMenu.nib to "First Responder > myCustomSaveMethod:".
Any ideas how to enable ⌘S-saving in the field editor in this case?
The reason this happened is that the "First Responder" is anything above the current view in the responder chain. The manually invoked field editor is inserted into the responder chain below NSWindowController. myCustomSaveMethod: is implemented in a sub-view controller which is not part of that responder chain, so the method definition isn't available to the field editor.
Moving myCustomSaveMethod: to a responder in the chain that both the table view and the field editor share (e.g. the NSWindowController) works like a charm.
¯\_(ツ)_/¯
I'm trying to remove focus from a UITextField and even though I resign it from being first responder, I'm still not able to have the cursor not focus on the text field.
I don't have any other input on the view to move the focus to and I don't want to create a dummy one either. What is a good workaround for this?
As per the documentation.
To dismiss the keyboard, send the resignFirstResponder message to the text field that is currently the first responder. Doing so causes the text field object to end the current editing session (with the delegate object’s consent) and hide the keyboard.
If you call resignFirstResponder on your textfield then it will end the editing session and the cursor wont be focussing on that textfield.
So please verify one more time whether resignFirstResponder is getting called on that textfield which you want to remove the focus.
Please try to set your current class as delegate of your UITextField. I think you forget to set the delegate that's why it's not working as you are expecting.
I'm trying to detect when user finishes editing a NSTextField by implementing NSTextFieldDelegate's controlTextDidEndEditing: method. However the problem is that upon initially making the NSTextField first responder of the window, immediately the controlTextDidEndEditing: notification gets fired. I tried this in an extremely simple test app and confirms the result. Would really appreciate some pointers on why this is the case and how to detect when textField loses focus.
As the text field is first Responder, selectText: message will also sent to textField, which will cause it to end editing. If you don't want this behavior set NO to selectable property of textField.
- (void)selectText:(id)sender;
Ends editing and selects the entire contents of the receiver if it’s selectable.
I'm working on an app that presents an NSPopover containing a number of NSTextFields. While I can tab between these fields as I expect, the popover is selecting a particular text field to be in the editing state when it appears, and it's not the field I want to edit; I'd like to be able to define which text field is editing on popover appearance programmatically (or in Interface Builder). How can I do this?
I've set up the appropriate key view loop by connecting IB outlets for all the various text fields involved, and I've hooked up the popover's nextResponder property to the text field I want to edit first, but that doesn't seem to have an effect - the popover will still select its preferred text field instead of mine. The Window Programming Guide suggests that I set the initialFirstResponder outlet of the window to the view I want selected, but an NSPopover is not an NSWindow and has no initialFirstResponder property (unless I'm missing something obvious).
Is there any way to specify which NSTextField I want to be editing when an NSPopover appears?
I think you said you tried using -makeFirstResponder: and passing the text field. This will set the window's firstResponder, but that's not the same as initialFirstResponder and the window must have initialFirstResponder set to something other than nil in order to respect the key view loop. (Source) A slight tweak to what you tried worked for me:
- (void)popoverWillShow:(NSNotification *)notification
{
// Set the window's initialFirstResponder so that the key view loop isn't auto-recalculated.
[[myField window] setInitialFirstResponder:myField];
}
I think you can make this work by setting all the text field's that you don't want to have focus to "selectable" instead of "Editable" in IB, this should leave the one text field you want to start with as the first responder. Then, in your popoverDidShow: method, set them all back to editable, and you should be able to tab between them as usual.
I have an NSTableView in a dialogue box which is bound to a collection of CoreData model instances via an NSArrayController in 'Entity Name' mode. The table displays the names of the array of managed objects in a single column. This works well.
The names in the table rows are editable. If the user edits a name when there is no sorting applied to the table then editing proceeds normally. After pressing Return, the new name is recorded and input focus stays in the NSTableView. However, if the column heading in the table view is clicked upon in order to sort the table of names, input focus goes astray after editing. It stays within the window, or wider view (not sure which), but it goes out of the table; the focus ring vanishes and the background colour of the highlighted item changes from blue to grey. Pressing Tab pops input focus back into the table view again.
This only happens if the table contents are sorted. If "Continuously Updates Value" is chosen for the binding, it's catastrophic as the minute any characters are entered, the table view seems to want to re-sort itself (that's OK) and focus jumps out of it (that's not OK as the user was in the middle of trying to type something).
As far as this aspect of the system is concerned, there's no code - it's all done with bindings established in Interface Builder. Presumably, I've inadvertently set or cleared some option that I shouldn't have.
In case it helps the reader figure out what's up - I also have a modal sheet attached to the dialogue box containing the NSTableView. The sheet is used to edit the details of an item selected in the table view. The controls in this are also connected with bindings to the CoreData model using the same NSArrayController as the dialogue box 'behind' the sheet. The same problem is seen - as soon as a new name is typed in, focus is pulled back to the dialogue box 'behind' the modal sheet.
The only code involved is that used to handle the 'edit this item' action and start the modal session for the sheet.
What's going on? Where is the focus going and why is being moved just because of re-sorting in the NSTableView?
Thanks!
The entities NSArrayController had "Auto Rearrange Content" ticked in the relevant Interface Builder inspector panel. This wasn't doing what I thought it would do and was the cause of the focus stealing problem.
I finally narrowed this down by creating a bare bones CoreData application which just added names to a table view. Almost no code required; 99.5% Interface Builder and bindings, with just an extra outlet and a single line of glue code to tell the array controller for the CoreData model about the Managed Object Context instantiated in the application delegate by code that Interface Builder had auto-generated. Setting the "Auto Rearrange Content" flag in the test program provoked the same strange input focus behaviour.
So if you've got focus stealing problems with a table of objects bound to CoreData through an array controller, check your array controller's auto-rearrange flag!