FROM : John Stiles
DATE : Tue Aug 01 19:09:30 2006
I will experiment some more with
performSelector:withObject:afterDelay:, then.
Do you think this merits a radar? I can see how Cocoa gets into this
botched up state, but I think the text field control ought to be
smart enough to realize that it doesn't deserve a halo if it doesn't
really have focus.
On Aug 1, 2006, at 9:38 AM, Matt Neuburg wrote:
> On Tue, 01 Aug 2006 08:30:40 -0700, John Stiles
> <<email_removed>> said:
>
>> I don't think it's apparent that a control in the window /must/ have
>> focus. The window itself, or the window frame container, can have the
>> focus. That's perfectly legitimate AFAICS. And I certainly don't
>> think
>> the impetus is on the developer to force focus on a control in a
>> window
>> whenever you show a window or sheet---this certainly isn't a common
>> Cocoa programming technique.
>
> Well, try it with a window containing nothing but an NSTextField
> (not in a
> tab view). When the app starts up and the window appears, the text
> field has
> focus. So exactly the same thing should happen even when the
> NSTextField
> *is* in a tab view.
>
> In any case, the problem you are having is merely a variety of a
> very old
> problem. You are hitting Return in the text field as a way
> triggering the
> default button. When Cocoa finishes triggering the default button,
> though,
> it puts the focus back where it was. Since you are changing the
> focus inside
> the button's action method, Cocoa puts the focus back where it was
> *after*
> the button's action method has finished. Delayed performance solves
> the
> problem, one way or another. This has been dealt with many times
> here, so
> check the archives. The solution I provided years go, though rather
> naively
> written (I was young and foolish in those days, and didn't really
> know what
> a selector was), still works - and it works in the case of your
> example,
> which is the important thing.
>
> <http://www.cocoabuilder.com/archive/message/cocoa/2002/9/16/70936>
>
> So:
>
> - (IBAction)goToSecondTab:(id)sender
> {
> [myTextField setStringValue:@""];
> [myTabView selectTabViewItemAtIndex:1];
> }
>
> - (BOOL)control:(NSControl *)control
> textView:(NSTextView *)textView doCommandBySelector:(SEL)
> command {
> if (command == @selector(insertNewline:)) {
> if ([[control window] makeFirstResponder: [control window]]) {
> [[[control window] defaultButtonCell]
> performSelector:@selector(performClick:)
> withObject: nil
> afterDelay: 0.05];
> }
> return YES;
> }
> return NO;
> }
>
> m.
>
> --
> matt neuburg, phd = <email_removed>, <http://www.tidbits.com/matt/>
> A fool + a tool + an autorelease pool = cool!
> AppleScript: the Definitive Guide - Second Edition!
> <http://www.amazon.com/gp/product/0596102119>
>
>
>
DATE : Tue Aug 01 19:09:30 2006
I will experiment some more with
performSelector:withObject:afterDelay:, then.
Do you think this merits a radar? I can see how Cocoa gets into this
botched up state, but I think the text field control ought to be
smart enough to realize that it doesn't deserve a halo if it doesn't
really have focus.
On Aug 1, 2006, at 9:38 AM, Matt Neuburg wrote:
> On Tue, 01 Aug 2006 08:30:40 -0700, John Stiles
> <<email_removed>> said:
>
>> I don't think it's apparent that a control in the window /must/ have
>> focus. The window itself, or the window frame container, can have the
>> focus. That's perfectly legitimate AFAICS. And I certainly don't
>> think
>> the impetus is on the developer to force focus on a control in a
>> window
>> whenever you show a window or sheet---this certainly isn't a common
>> Cocoa programming technique.
>
> Well, try it with a window containing nothing but an NSTextField
> (not in a
> tab view). When the app starts up and the window appears, the text
> field has
> focus. So exactly the same thing should happen even when the
> NSTextField
> *is* in a tab view.
>
> In any case, the problem you are having is merely a variety of a
> very old
> problem. You are hitting Return in the text field as a way
> triggering the
> default button. When Cocoa finishes triggering the default button,
> though,
> it puts the focus back where it was. Since you are changing the
> focus inside
> the button's action method, Cocoa puts the focus back where it was
> *after*
> the button's action method has finished. Delayed performance solves
> the
> problem, one way or another. This has been dealt with many times
> here, so
> check the archives. The solution I provided years go, though rather
> naively
> written (I was young and foolish in those days, and didn't really
> know what
> a selector was), still works - and it works in the case of your
> example,
> which is the important thing.
>
> <http://www.cocoabuilder.com/archive/message/cocoa/2002/9/16/70936>
>
> So:
>
> - (IBAction)goToSecondTab:(id)sender
> {
> [myTextField setStringValue:@""];
> [myTabView selectTabViewItemAtIndex:1];
> }
>
> - (BOOL)control:(NSControl *)control
> textView:(NSTextView *)textView doCommandBySelector:(SEL)
> command {
> if (command == @selector(insertNewline:)) {
> if ([[control window] makeFirstResponder: [control window]]) {
> [[[control window] defaultButtonCell]
> performSelector:@selector(performClick:)
> withObject: nil
> afterDelay: 0.05];
> }
> return YES;
> }
> return NO;
> }
>
> m.
>
> --
> matt neuburg, phd = <email_removed>, <http://www.tidbits.com/matt/>
> A fool + a tool + an autorelease pool = cool!
> AppleScript: the Definitive Guide - Second Edition!
> <http://www.amazon.com/gp/product/0596102119>
>
>
>
| Related mails | Author | Date |
|---|---|---|
| John Stiles | Jul 28, 04:15 | |
| John Stiles | Jul 31, 22:54 | |
| Wagner Truppel | Jul 31, 23:45 | |
| John Stiles | Aug 1, 00:03 | |
| Ricky Sharp | Aug 1, 02:24 | |
| John Stiles | Aug 1, 02:53 | |
| Matt Neuburg | Aug 1, 17:14 | |
| John Stiles | Aug 1, 17:30 | |
| Ricky Sharp | Aug 1, 18:22 | |
| Ricky Sharp | Aug 1, 18:25 | |
| Matt Neuburg | Aug 1, 18:38 | |
| John Stiles | Aug 1, 19:09 | |
| Matt Neuburg | Aug 1, 19:35 |






Cocoa mail archive

