Re: Re(2): NSTextField selectText behaviour (Currency Converter Tut)
Re: Re(2): NSTextField selectText behaviour (Currency Converter Tut)
- Subject: Re: Re(2): NSTextField selectText behaviour (Currency Converter Tut)
- From: Bryan Blackburn <email@hidden>
- Date: Sat, 18 Jan 2003 14:27:14 -0700
- Mail-followup-to: Cocoa Dev <email@hidden>
Note that the performSelector:target:argument:order:modes: method isn't
actually doing anything with threads, other than being sent to the
current run loop of the current thread. The important concept here is that
this will cause the selector to be sent later, the next time the current
run loop handles what's on the queue. If you're using something like this
which affects the interface, and you are using multiple threads, things
get a bit more messy.
Bryan
On Jan 18, 2003 20:33, Lachlan Deck stated:
>
Hi Bryan,
>
>
thanks very much; that's excellent!
>
>
I can see that I have much to learn about Cocoa, but that threading is
>
built in is a good thing and it all seems cool (but frustrating at the
>
same time trying to figure out what should be obvious). The GUI elements
>
seem much better to work with than Java, however figuring stuff out in
>
Java seems easier (even when stuff like the GridBagLayout is clunky to
>
work with).
>
>
Thanks again for this simple solution.
>
It does make me wonder, however, as the API for NSRunLoop reckons that
>
you wouldn't need to call this class...."In general, your application
>
does not need to either create or explicitly manage NSRunLoop objects.
>
Each NSThread, including the application's main thread, has an NSRunLoop
>
object automatically created for it."
>
>
That said, however, it makes perfect sense to me that you would call it
>
for events that you want to make sure are executed after/before
>
others....
>
>
cheers.
>
>
On Saturday, January 18, 2003, at 03:48 PM, Bryan Blackburn wrote:
>
>
>What I've done in a similar situation is throw the change into the
>
>run loop instead of doing it immediately. For the currency example:
>
>
>
> [ [ NSRunLoop currentRunLoop ]
>
> performSelector:@selector( selectText: )
>
> target:rateField
>
> argument:self
>
> order:9999
>
> modes:[ NSArray arrayWithObject:NSDefaultRunLoopMode ] ];
>
>
>
>This replaces [ rateField selectText:self ].
>
>
>
>This way, it's done "in a moment" instead of now, after the text field
>
>has been handled.
>
>
>
>Bryan
>
>
>
>
>
>On Jan 18, 2003 10:23, Lachlan Deck stated:
>
>>Hi there,
>
>>
>
>>Okay - I haven't got any responses yet from someone who knows what's
>
>>happening here, so any help would be much appreciated.
>
>>
>
>>Cheers.
>
>>
>
>>On Friday, January 17, 2003, at 04:53 PM, Lachlan Deck wrote:
>
>>
>
>>>Hi there,
>
>>>
>
>>>Okay, I've checked the archives and what I'm seeing is commonly
>
>>>experienced by most.
>
>>>In ConverterController.m I have the following...
>
>>>
>
>>>- (IBAction)convert:(id)sender
>
>>>{
>
>>> ...
>
>>> [rateField selectText:self];
>
>>>}
>
>>>
>
>>>Now what most people experience is that if you click the Convert
>
>>>button, then the NSTextField, rateField, gains the focus and its text
>
>>>is selected. However, if the user presses the Enter or Return key
>
>>>(even
>
>>>though it's set to be the Equiv in Interface Builder) that the
>
>>>currently selected NSTextField retains the selection.
>
>>>
>
>>>I'm guessing that there is a conflict of interest here. i.e., an
>
>>>NSTextField reacts to a typed key (such as Return), however we are
>
>>>trying to remove the focus from the field (which happens automatically
>
>>>if you click with the mouse on the Convert button).
>
>>>
>
>>>What is the easiest way to, for example, unconditionally focus the
>
>>>cursor (and thus with selectText method above) for an NSTextField?
>
>
with regards,
>
>
--
>
Lachlan Deck
>
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.