Re: Custom view, selection consistency with NSTableView
Re: Custom view, selection consistency with NSTableView
- Subject: Re: Custom view, selection consistency with NSTableView
- From: Paul Szego <email@hidden>
- Date: Sun, 17 Apr 2005 20:26:28 +1200
On 17/04/2005, at 6:12 PM, mmalcolm crawford wrote:
On Apr 16, 2005, at 10:17 PM, Paul Szego wrote:
I assume you're referring to the GraphicsBinding example? If so, it's not quite what I'm after. I want to provide a contiguous selection, as my graphical layout does lend itself to the notion of ordering. So if you click on one object, and then shift-click on another it should make all objects in between selected also. The graphics binding example doesn't do this (I assume as the notion of ordering doesn't really apply here due to the layout of the dots).
The same principles apply.
The fact that it uses bindings is orthogonal to the selection. The example does support multiple selection from within the graphic view. It's up to you to write the selection logic for your own view...
Yes, I know this - the first part of the post says that's what I'm doing. I've already written code to cover the simple cases.
The issue is that the "standard" behaviour documented in the Human Interface Guide doesn't have enough detail. If I were to follow that
only, I could easily end up with behaviour different from other "standard" controls such as NSTableView. I covered one such scenario in the original post, but the vague areas are around shift-clicks and the "addition model" for contiguous selections.
The limited example in the HIG only illustrates some cases for selection inside text, not a list, and even that seems flawed.
The question was: "
... before I try to nail this down from observation, is it documented anywhere just what the "standard" behaviour is? I've read the Human Interface Guide, but the details on selection in lists doesn't appear to go into this much detail. Does anyone have any ideas or pointers to further information?"
Paul.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden