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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
