Re: over-riding keyDown
Re: over-riding keyDown
- Subject: Re: over-riding keyDown
- From: Matt Neuburg <email@hidden>
- Date: Thu, 21 Apr 2005 14:24:49 -0700
On Thu, 21 Apr 2005 10:43:40 -0400, John James <email@hidden> said:
>I have a non-main window that has a few user write-able text fields.
>It has a button
>which puts the model into a mode ("running") during which I want it to
>use my own keyDown to intercept keyevents. My keyDown is in my
>overridden NSWindowController which is a delegate for the given window
>we are talking about. It never gets called.
keyDown does not get sent to a window delegate (qua delegate). It does get
sent to a window controller, provided this window is the controller's
window, and of course provided nothing else eats the keyDown first.
>I tried to bind the "editable" property and the "enable" property of
>the textfields to a BOOL which is true when I am not in the "running"
>state. This seems to prevent the editing of the fields when we are in
>the "running mode but "does not allow my keyDown to be called.
>
>This used to work in a different window when I had the first responder
>a NSTableView. Unfortunately there are no tableviews in this window.
>That probably was a bad design as the user could leave the cursor in an
>editable field and the desired behavior would not work.
It works fine for me. If the text fields are not editable/enabled, key
presses are passed on to the window controller as keyDown events. m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide
<http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden