Re: Preventing textfield in table from clicking default button
On Aug 16, 2014, at 9:03 PM, Ken Thomases wrote: > The general mechanism is to implement the control delegate method > -control:textView:doCommandBySelector: and alter the response to the > "insertNewline:" selector. Thank you. That's exactly the right thing to do. I've used it before for different things, but not often or recently enough to remember it, and I was still futzing around higher in the stack trying to find something there. For posterity: the textDidBeginEditing/textDidEndEditing method won't work if the text actually doesn't change so don't use that. -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preventing textfield in table from clicking default button
> On 2014/08/17, at 13:03, Ken Thomases wrote: > > > I recommend that you do a variant of the technique outlined in Technical Q&A > QA1454: How to make NSTextField accept tab, return and enter keys. > https://developer.apple.com/library/mac/qa/qa1454/_index.html > > The general mechanism is to implement the control delegate method > -control:textView:doCommandBySelector: and alter the response to the > "insertNewline:" selector. > > You're not interested in inserting the newline into the text, but you can > adjust the response to the return key in other ways. If you return YES, you > stop any further processing of the selector. That allows you to have > complete control over the response. As to what you do before returning YES, > I think it should be sufficient to make another view (or the window itself) > the window's first responder using -[NSWindow makeFirstResponder:]. > > Probably, making the table view itself the first responder makes the most > sense, although perhaps there's an intervening ancestor view between the text > field and the table view that would make more sense in your case. Or perhaps > you could just delegate the logic to -[NSWindow selectNextKeyView:], to make > it as though the user had hit Tab instead of return. (I would be amused by > the irony of subverting the Tech Q&A by translating an invocation of > -insertNewline: into an invocation of -insertTab:, too.) > > Regards, > Ken Remember the field editor defaults to a shared instance of NSTextView basically that is owned by the window. You can always create a unique one and assign it to your text fields. This is a bit more heavy weight than the simpler delegate approach but also gives complete control while allowing you to use the default field editor for text fields outside your table. Though the delegate approach should give you just the same ability if you check where the text field belongs in some way. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preventing textfield in table from clicking default button
On Aug 16, 2014, at 9:53 PM, Seth Willits wrote: > When editing in a NSTextField and return is pressed, it fires the text > field's action and also sends performKeyEquivalent: to the window, which > clicks the default button. Usually that's just fine, but in the case where a > view-based table view has editable NSTextFields in it, this makes no sense. > > Anybody figured out how to prevent this? I recommend that you do a variant of the technique outlined in Technical Q&A QA1454: How to make NSTextField accept tab, return and enter keys. https://developer.apple.com/library/mac/qa/qa1454/_index.html The general mechanism is to implement the control delegate method -control:textView:doCommandBySelector: and alter the response to the "insertNewline:" selector. You're not interested in inserting the newline into the text, but you can adjust the response to the return key in other ways. If you return YES, you stop any further processing of the selector. That allows you to have complete control over the response. As to what you do before returning YES, I think it should be sufficient to make another view (or the window itself) the window's first responder using -[NSWindow makeFirstResponder:]. Probably, making the table view itself the first responder makes the most sense, although perhaps there's an intervening ancestor view between the text field and the table view that would make more sense in your case. Or perhaps you could just delegate the logic to -[NSWindow selectNextKeyView:], to make it as though the user had hit Tab instead of return. (I would be amused by the irony of subverting the Tech Q&A by translating an invocation of -insertNewline: into an invocation of -insertTab:, too.) Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Preventing textfield in table from clicking default button
On Aug 16, 2014, at 7:53 PM, Seth Willits wrote:
> This is leaving me little choice but to do something very specialized and
> ugly.
Well… the simplest solution is to just disable the key equivalent myself
instead of using NSWindow's methods. I don't like it, but it does work in my
case...
- (void)textDidBeginEditing:(NSNotification *)notification;
{
self.window.defaultButtonCell.keyEquivalent = @"";
[super textDidBeginEditing:notification];
}
- (void)textDidEndEditing:(NSNotification *)notification;
{
[super textDidEndEditing:notification];
self.window.defaultButtonCell.keyEquivalent = @"\r";
}
--
Seth Willits
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Preventing textfield in table from clicking default button
When editing in a NSTextField and return is pressed, it fires the text field's
action and also sends performKeyEquivalent: to the window, which clicks the
default button. Usually that's just fine, but in the case where a view-based
table view has editable NSTextFields in it, this makes no sense.
Anybody figured out how to prevent this?
---
It happens in NSTextField textDidEndEditing, so there's no stopping
performKeyEquivalent: from being called short of subclassing NSTextField and
reimplementing that method. (Eww)
You also can't disable the key equivalent on the button in
controlTextDidBeginEditing and re-enable it in controlTextDidEndEditing,
because the performKeyEquivalent: is called after the controlTextDidEndEditing
notification is sent.
I thought maybe I could so some light NSTExtField subclassing and use
NSWindow's disableKeyEquivalentForDefaultButtonCell...
@implementation MyTableCellTextField
- (void)textDidBeginEditing:(NSNotification *)notification;
{
[self.window disableKeyEquivalentForDefaultButtonCell];
[super textDidBeginEditing:notification];
}
- (void)textDidEndEditing:(NSNotification *)notification;
{
[super textDidEndEditing:notification];
[self.window enableKeyEquivalentForDefaultButtonCell];
}
@end
Sadly, that doesn't work. My default button is still clicked when [super
textDidEndEditing:] calls performKeyEquivalent:, despite the defaultButtonCell
being the right button… As a matter of fact, looking at the implementation of
those NSWindow methods shows they're identical to each other… which makes
absolutely no sense. So obviously that doesn't do what one would expect.
This is leaving me little choice but to do something very specialized and ugly.
Am I missing something?
--
Seth Willits
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
