Re: Regarding these Olivia messages. Can we do something about the list security?
> On 30 Jul 2015, at 18:16, Alex Zavatone wrote: > > > On Jul 30, 2015, at 9:45 AM, Shane Stanley wrote: > >> On 30 Jul 2015, at 9:36 pm, Alex Zavatone wrote: >>> >>> Including me, I know of three people who have gotten these. >> >> FWIW, it's also happening to on at least one other Apple mailing list. >> Olivia seems to get around. > > Which other ones? I haven't seen them on ASOC or the Applescript ones (which > I am aware you are subbed to). I’m guessing that a bone fide user has an infected machine, if this is the case, then it’s whatever lists they are subscribed to. It helps if you strip all email addresses except the list from your replies. If you want to reply to the sender too, send it as two separate emails. Cheers Dave ___ 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
Programmatically switching text fields
I think this came up recently in a slightly different context, but reading that
thread doesn’t help me with my problem here.
I have a series of NSTextFields and I want to automatically move the keyboard
focus to the ‘next’ field when the one preceding it has a certain number of
characters entered. My code is:
- (void)controlTextDidChange:(NSNotification*) obj
{
NSTextField* control = [obj object];
NSString* text = [control stringValue];
if([text length] >= 4 )
{
NSString* shortStr = [[text substringToIndex:4]
uppercaseString];
[control setStringValue:shortStr];
NSResponder* nextField = [control nextKeyView];
NSLog(@"got 4 characters: '%@', moving to field: %@", shortStr,
nextField );
[[self window] makeFirstResponder:nextField];
}
}
This code is in a NSWindowController subclass, and I have set up the
‘nextKeyView’ of each fireld to be the next one along, and I’ve also verified
that these are all set correctly, as is the ‘window’ outlet, so the line
[[self window] makeFirstResponder:nextField];
is called, and does have all valid parameters.
The window controller is set as the delegate of the fields so that it receives
the -controlTextDidChange message as the user types in the fields. This is
definitely called on every keystroke, and the code does what it should,
detecting the string length and calling -makeFirstResponder when it gets a
length of 4 or more (as a side effect it also forces whatever the user has
types to be uppercase but that’s not important here).
The current field does lose focus, but the next field never gains it, so the
flow of text entry from field to field doesn’t occur as it should. Also, even
though the first field is set as the window’s initialFirstResponder, and does
get the keyboard focus ring, the actual field editor isn’t ready and typing
just produces a beep - the user has to click in the field to make it accept
text. These probems may well be related.
I should point out that this did work in the past for some version of the OS,
but it doesn’t work in 10.10 - I don’t know at what version it stopped working.
I’ve tried calling -makeFirstResponder after a delay, but it doesn’t help. I’m
using a custom field editor (NSTextView subclass), but if I disable that so it
uses the standard one, the faulty behaviour doesn’t change.
What’s the currently supported way to programmatically switch among text
fields? Or is it simply broken in the OS at the moment?
—Graham
___
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: Programmatically switching text fields
On Aug 2, 2015, at 7:29 PM, Graham Cox wrote:
> I have a series of NSTextFields and I want to automatically move the keyboard
> focus to the ‘next’ field when the one preceding it has a certain number of
> characters entered. My code is:
>
> - (void) controlTextDidChange:(NSNotification*) obj
> {
> NSTextField* control = [obj object];
>
> NSString* text = [control stringValue];
>
> if([text length] >= 4 )
> {
> NSString* shortStr = [[text substringToIndex:4]
> uppercaseString];
> [control setStringValue:shortStr];
>
> NSResponder* nextField = [control nextKeyView];
>
> NSLog(@"got 4 characters: '%@', moving to field: %@", shortStr,
> nextField );
>
> [[self window] makeFirstResponder:nextField];
> }
> }
You can try [[self window] selectKeyViewFollowingView:control] instead.
If that doesn't work, you can try [control.currentEditor
tryToPerform:@selector(insertTab:) with:self].
> … the code does what it should, detecting the string length and calling
> -makeFirstResponder when it gets a length of 4 or more …
>
> The current field does lose focus, but the next field never gains it, so the
> flow of text entry from field to field doesn’t occur as it should. Also, even
> though the first field is set as the window’s initialFirstResponder, and does
> get the keyboard focus ring, the actual field editor isn’t ready and typing
> just produces a beep - the user has to click in the field to make it accept
> text. These probems may well be related.
Are you certain the window is key? Does your app do anything unusual with
activationPolicy or activation, generally?
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: Programmatically switching text fields
> On 3 Aug 2015, at 12:13 pm, Ken Thomases wrote: > > You can try [[self window] selectKeyViewFollowingView:control] instead. Great! That works fine. The only problem remaining then is that the first field isn’t properly selected when the window shows up - it is initialFirstResponder and gets the key focus ring, but you can actually type text until you click in it again. > Are you certain the window is key? Does your app do anything unusual with > activationPolicy or activation, generally? I don’t do anything unusual that I can see - it’s a fairly simple NSPanel. Thinking further, I do have a NSTabView between the window and these fields, and the tab on which the fields are placed are not on the default tab. I seem to recall there were issues with tab views a long time ago, and perhaps it’s naive to assume they’re fixed. It’s also probable that setting initialFirstResponder to an item that’s not on the displayed tab might fail, though it’s weird that it leaves it in a half-selected state. I’ll look at responding to the tab delegate methods to select the field when the tab is switched. —Graham ___ 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: Programmatically switching text fields
On Aug 2, 2015, at 11:01 PM, Graham Cox wrote: > On 3 Aug 2015, at 12:13 pm, Ken Thomases wrote: >> >> You can try [[self window] selectKeyViewFollowingView:control] instead. > > Great! That works fine. Glad to hear it. > The only problem remaining then is that the first field isn’t properly > selected when the window shows up - it is initialFirstResponder and gets the > key focus ring, but you can actually type text until you click in it again. > >> Are you certain the window is key? Does your app do anything unusual with >> activationPolicy or activation, generally? > > I don’t do anything unusual that I can see - it’s a fairly simple NSPanel. The default implementation of -canBecomeMainWindow returns NO for panels. Is your window intended to be the main window? Is it actually? Does it change anything if you add an override to return YES? > Thinking further, I do have a NSTabView between the window and these fields, > and the tab on which the fields are placed are not on the default tab. I seem > to recall there were issues with tab views a long time ago, and perhaps it’s > naive to assume they’re fixed. It’s also probable that setting > initialFirstResponder to an item that’s not on the displayed tab might fail, > though it’s weird that it leaves it in a half-selected state. I’ll look at > responding to the tab delegate methods to select the field when the tab is > switched. Are you aware that NSTabViewItem has its own initialFirstResponder property? Have you tried using that? 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: Programmatically switching text fields
> On 3 Aug 2015, at 2:28 pm, Ken Thomases wrote: > > The default implementation of -canBecomeMainWindow returns NO for panels. Is > your window intended to be the main window? Is it actually? Does it change > anything if you add an override to return YES? Well, it doesn’t need to be main, it only needs to become key. Overriding it is a pain because all the custom code is in a NSWindowController subclass, so needing an additional NSPanel subclass creates a lot of development friction. However, since I have now fixed this, it’s a moot point... > Are you aware that NSTabViewItem has its own initialFirstResponder property? > Have you tried using that? That makes total sense, and I wasn’t aware of it. However, it doesn’t fix the problem in this case - it acts the same way as having it be the window’s initialFirstResponder.. What has worked is a) implement the tab view delegate to request that the window selects the first field by invoking -selectKeyViewFollowingView:, passing its predecessor, and b) remove all the code I had added in various places to try and force the first responder to be the first field (e.g. calling makeFirstResponder from -windowDidLoad). This is OK for my case, because the fields all live on the tab that isn’t shown initially, so there will always be a tab switch before the user sees the field for the first time. Reselecting that field if they switch away and back is OK as well. I don’t think this is a very general solution, but it may well be that for fields on the default tab, initialFirstResponder on the window or tab view will work (not tried). Does seem a bit buggy overall though, in the rush to animate everything (key focus ring here) some basic functionality has got broken. —Graham ___ 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
