Re: OK on Enter, not Return

FROM : Andrew Merenbach
DATE : Fri Jun 06 21:29:52 2008

Quoting Douglas Davidson <<email_removed>>:

>
> On Jun 6, 2008, at 11:19 AM, Andrew Merenbach wrote:
>

>> I believe that you might do some magic with -keyDown: -- I'm sure 
>> that someone else will have more knowledge about this -- but bear 
>> in mind that the latest-gen MacBooks (of which I have one) do not 
>> have separate Return and Enter keys -- just one.  (Maybe the fn 
>> button changes it, but even if so, users would have to figure that 
>> out.)  What about making alt-Enter/alt-Return add a newline, while 
>> leaving Return and Enter both to do the job of activating the OK 
>> button? Hope this helps, even if only a little!

>
> Here is something I wrote on this before:
>
> Here is the normal sequence when a text view receives key events:
>
> NSTextView's keyDown: passes events to interpretKeyEvents:, which is
> where they enter key binding and input management.  They come out
> either as insertText: or as doCommandBySelector: (see NSResponder.h for
> these three methods).
>
> In particular, non-text keys like enter or return will (with the
> standard key bindings) end up using doCommandBySelector: to call
> methods like insertNewline: on the NSTextView.
>
> If you are using an NSTextView, you should be able to implement the
> text view delegate method
>
> - (BOOL)textView:(NSTextView *)aTextView doCommandBySelector:(SEL)aSelector;
>
> and examine the selector.
>
> If you are using an NSTextField or similar control, you can implement
> their delegate method
>
> - (BOOL)control:(NSControl *)control textView:(NSTextView *)textView
> doCommandBySelector:(SEL)aSelector;
>
> If you wish to do something different at this point, you might (for
> example) look at the current event and ascertain whether it is a key
> down and if so, what key it is.
>
> In most cases you don't actually want to intervene at keyDown: time.
> That's because keyDown: takes place before all of the key binding and
> input management that is necessary in general to make sense of
> keystrokes; it would be easy, for example, for you to break input
> methods like those used for East Asian text.  One possibility would be
> to use a keyDown: override to determine whether a particular keystroke
> is enter or return, but not to make any modifications at that point;
> instead, you could use that information to set a flag that would later
> be used at doCommandBySelector time.
>
> Douglas Davidson


You are right, Douglas, and although I had seen your prior writings 
(referenced at least twice, I'm sure, in separate discussions), I had 
not recalled them.  My argument about the Return/Enter on MacBook 
keyboards still seems an issue to me, though.

Cheers,
Andrew