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: Michael Crawford <email@hidden>
- Date: Tue, 16 Aug 2011 15:58:24 -0400
On Aug 16, 2011, at 3:51 PM, Conrad Shultz wrote:
> -----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?
Yes it is.
>
> 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.
>
I like it. There are some other issues that come out of this but they are minor. I'm in the middle of experimentation. If I don't find something I like better, this is a good fallback position.
-Michael
>
> - --
> 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