I have a cell-based NSTableView with an editable text field. Sometimes, seemingly randomly, after choosing to edit the field and typing a few characters, the field exits edit mode and I am left unable to edit the value.
Closing the document and reopening fixes it for a while.
What might be causing this?
It is bound to an NSArrayController and I believe that NSConditionallySetsEditableBindingOption is true by default.
Related
Look at the simple app screenshot below. There is a text field and a segmented control. There are three bindings in play:
textfield value binding goes to NSUserDefaultsController values.TextValue
textfield alignment binding goes NSUserDefaultsController values.Alignment
segmented control selectedIndex binding goes to NSUserDefaultsController values.Alignment
So the segmented control controls the text field's alignment.
Problem:
When the text field has first responder, if you click on the segmented control to change the alignment, the text field 1.) throws out the value being edited and reverts to the last bound value, 2.) does not update its alignment, 3.) remains first responder.
Expected behavior would be: when you change the segmented control value the text field resigns first responder, commits the value in the UI to user defaults, and updates its alignment. How can this be done?
You’ve hit a bug and should report a RADAR. There have been many bugs with textfields and bindings when you’re editing a textfield, it’s not an area the engineers focused on originally.
You don’t even need to bind the textField’s value to replicate this, you can just bind the alignment of the textField.
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.
Quick question! When any NSFormCell becomes the first responder, its placeholder text becomes that of the last NSTextField to have focus. Here's an illustration: http://i.imgur.com/3dlzj.jpg
However, the NSTextFields never encounter this! Have you seen this before? This is happening in Xcode 4.3 — what thoughts do you have?
Thank you!
This isn't an answer, but just some further observations.
I did some experimenting with this, and it's not anything you're doing. If you just drag a form and a text field into a window in IB, and put a placeholder string in the text field, then that placeholder appears in the form if you first select the text field and then one of the form cells (with no code at all in the app). It doesn't matter whether you put any placeholder in the form in IB, it still gets the one from the text field. I also put a button in the window with an action that logs the placeholderString of one of the cells -- it always logs null, even though it shows the text field's placeholder. If you put a placeholder in that cell (in IB), then it logs that placeholder, but if you select the text field and then that cell, the text field's placeholder shows up, but the log still shows the original placeholder.
This looks like a bug to me. It might have something to do with the field editor? Isn't there a shared field editor for all text fields in a view?
I have a view-based outline view (OSX 10.7). Clicking on an item selects it, as usual. Double clicking allows editing of the textfield it contains. However, when I'm done editing the textField, the row's highlight disappears. The outlineView still thinks the row is selected, and sending that row a drawSelectionInRect message doesn't change its appearance. Telling the outlineView to again select the row also doesn't change its appearance. Only by again clicking on the row can I get the highlight to reappear. Any idea what's going on?
My fault. I'm observing changes to the managedObjectContext, and was reloading the entire tree when individual items changed: by correcting this to reload only the affected item, things work as they should.
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!