Re: Responding to the keyboard in an NSCell
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 (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
Re: Responding to the keyboard in an NSCell
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. --Graham ___ 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
Re: Responding to the keyboard in an NSCell
On 25 Nov 2010, at 10:46, Graham Cox wrote: > > On 25/11/2010, at 9:37 PM, Thomas Davie wrote: > >> I'm trying to implement an NSCell which should be able to respond to the >> user pressing backspace to delete something, but I don't quite see how >> keyboard handling is meant to work. The - (BOOL)acceptsFirstResponder >> method seems to suggest that NSCell *should* be an NSResponder subclass. It >> isn't though, and it doesn't get sent things like -keyDown: if you return >> YES from acceptsFirstResponder. >> >> I get the feeling that I'm missing something obvious here, but I could do >> with a prod in the right direction. > > > A cell is usually a component of a view. The view is the responder, but I > presume the -acceptsFirstResponder method in NSCell is really there so that > the host view can defer to its cell to answer that question. 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? > If you want to use the cell in a standard view, such as a tableview , matrix, > or other control, you'll have to figure out how those classes interact with > their cells. If it's in a custom view of your own, you can probably be more > loose with how you do it, if compatibility with standard controls isn't > required. Though in that case, you could just make a custom 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 :/ Thanks Tom Davie___ 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
Re: Responding to the keyboard in an NSCell
On 25/11/2010, at 9:37 PM, Thomas Davie wrote: > I'm trying to implement an NSCell which should be able to respond to the user > pressing backspace to delete something, but I don't quite see how keyboard > handling is meant to work. The - (BOOL)acceptsFirstResponder method seems to > suggest that NSCell *should* be an NSResponder subclass. It isn't though, > and it doesn't get sent things like -keyDown: if you return YES from > acceptsFirstResponder. > > I get the feeling that I'm missing something obvious here, but I could do > with a prod in the right direction. A cell is usually a component of a view. The view is the responder, but I presume the -acceptsFirstResponder method in NSCell is really there so that the host view can defer to its cell to answer that question. If you want to use the cell in a standard view, such as a tableview , matrix, or other control, you'll have to figure out how those classes interact with their cells. If it's in a custom view of your own, you can probably be more loose with how you do it, if compatibility with standard controls isn't required. Though in that case, you could just make a custom view. --Graham ___ 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
Responding to the keyboard in an NSCell
I'm trying to implement an NSCell which should be able to respond to the user pressing backspace to delete something, but I don't quite see how keyboard handling is meant to work. The - (BOOL)acceptsFirstResponder method seems to suggest that NSCell *should* be an NSResponder subclass. It isn't though, and it doesn't get sent things like -keyDown: if you return YES from acceptsFirstResponder. I get the feeling that I'm missing something obvious here, but I could do with a prod in the right direction. Thanks Tom Davie___ 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
