Re: How can I prevent drag-and-drop initiation in an NSTextField
Re: How can I prevent drag-and-drop initiation in an NSTextField
- Subject: Re: How can I prevent drag-and-drop initiation in an NSTextField
- From: Conrad Shultz <email@hidden>
- Date: Tue, 16 Aug 2011 12:51:12 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/16/11 12:15 PM, Michael Crawford wrote:
> If that's your goal, why don't you just setEditable:NO ?
>
> I tried that. The only problem is that then I cannot display the
> keys the user taps as they happen. I'm injecting keyboard events
> and the textfield is the responder. I could bypass the keyboard
> input altogether and just have the keyboard buttons add the
> appropriate character to a string which is then written to the
> textfield but we have other reasons for wanting this to response as
> if a real keyboard was plugged in.
>
> Please don't focus on the constraints I just described.
OK, I will refrain from further comment on this constraint.
> Does anyone know of a way to prevent drag and drop from an
> NSTextField? This is all I'm trying to accomplish.
Since blocking drag and drop likely will require a subclass along the
lines you described, it is probably still worth some effort to determine
whether your goal can be differently accomplished.
If I understand correctly, you need the field to be editable because it
is the first responder and you need it to handle key input, whether from
a physical keyboard or from events injected into the event stream. Is
that a correct interpretation?
If so, I would ask why you don't simply handle these events higher up -
say, in a container view or the corresponding NSWindow or
NSWindowController? These objects could (maybe even already do) have
references to the text field (which could just be treated as a label
now) and could implement -keyDown: and the like, dispatching updates to
the text field when required.
The upshot is that by handling the events higher in the responder chain:
1) You still get to handle keyboard input just as you desire.
2) Since you are likely already implementing a subclass for one of these
responder objects you can avoid unnecessary further subclassing.
3) You will have a much less fragile architecture when the you or the
designers inevitably decide that the string needs to also be displayed
elsewhere on the screen, etc.
Would this work? Please correct me if I do not understand your
objectives properly.
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD4DBQFOSsowaOlrz5+0JdURAgy6AJY3t+ObRV8Xx6k0KYKapUUPW6MaAJ0cCCfF
Lhpv/odeJKLKxTYVILa2WQ==
=fMCI
-----END PGP SIGNATURE-----
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden