Re: Responding to the keyboard in an NSCell
Re: Responding to the keyboard in an NSCell
- Subject: Re: Responding to the keyboard in an NSCell
- From: Thomas Davie <email@hidden>
- Date: Thu, 25 Nov 2010 11:38:57 +0000
On 25 Nov 2010, at 11:30, Graham Cox wrote:
>
> On 25/11/2010, at 10:12 PM, Thomas Davie wrote:
>
>> Surely in order to defer control though there would have to be some protocol defined somewhere that tells us how a view can ask a cell for help in responding to the keyboard?
>
> Cells are mostly designed, as far as I can see, to relieve the view of a repetitive drawing task. Where they have an editing function, that's handled by the Field Editor, another view.
>
>> Unfortunately, I'm embedding these in an outline view, my current thinking is to subclass NSOutlineView and hack my own responder events to talk to my cell, but it seems a bit of a hack – it embeds part of the semantics of my cell in a class elsewhere, and stops the cell being composible in other scenarios. If there really is no real way to do this though, I guess it's what I'll have to do :/
>
>
> The view is the only part that directly responds to the keyboard. You could just pass everything to the cell, but then it wouldn't work the same in a standard control. There is no defined protocol beyond the usual control <--> cell methods which allow you to, e.g. start and stop editing, but do not go further down to individual key events, which are handled by the Field Editor. There are further interactions between the Field Editor and the cell though, maybe your cell could use the FE in a standard way for editing?
>
> I've made a few NSCell subclasses in my time, and every time it was a deal of trouble. In your case if you want to use NSOutlineView as a host you'll probably have to accept the hassle, or try to make your cell fit in a more standard way.
>
> Sorry the advice is rather vague - every case seems to be different.
Yep, NSCell certainly seems to introduce a whole bundle of corner cases – this is the second of any significance I've tried to implement, and each has thrown up different bizarre behaviours.
Here's hoping that now that drawing efficiency is less of an issue, apple can refactor NSOutlineView and NSTableView into an NSOutlineView2 that uses something more akin to CocoaTouch's cells (that are still views) for drawing.
Tom Davie_______________________________________________
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