On 26 Jan 2012, at 2:13, Benny Kj?r Nielsen wrote:
> I already subclass NSTokenField and I believe I've googled and read
> everything related to NSTokenField. It took far to long before I gave
> up ;-)
Nooo! Mean Apple, not providing the hooks needed to fix things.
> And speaking of ways to c
On 26 Jan 2012, at 8:57, Seebs wrote:
>> Now that may not be a bad idea, but the problem with NSTokenField is
>> that it is difficult to monitor drag events. As I wrote previously I
>> forgot the ugly details, but as I recall I concluded that the only
>> way forward was probably to subclass the
On 26 Jan 2012, at 0:27, Seebs wrote:
> On 25 Jan 2012, at 17:23, Benny Kj?r Nielsen wrote:
>
>> I agree. I use Apples NSTokenField class for the address fields and
>> so far I have been unable to track drag'n'drop actions such that I
>> could remove an address from a source NSTokenField. If any
On 26 Jan 2012, at 1:49, Benny Kj?r Nielsen wrote:
> I almost decided to give an answer to that argument in my first reply
> :-) First, anything is possible and I did not claim that it was not
> possible to do it. I claimed it was non-trivial.
Wait, a perfectly obvious function that any develop
On 25 Jan 2012, at 21:12, Seebs wrote:
> 1. I would like a Reply-To-List button.
Noted.
> 2. If I drag an address from To to Cc, or vice versa, I think the
> default should be to move it rather than duplicating it. I can't see
> any benefit to having one address in two recipient fields.
I
On 25 Jan 2012, at 17:23, Benny Kj?r Nielsen wrote:
> I agree. I use Apples NSTokenField class for the address fields and so
> far I have been unable to track drag'n'drop actions such that I could
> remove an address from a source NSTokenField. If anyone has any code
> which does something like
Issues:
1. I would like a Reply-To-List button.
2. If I drag an address from To to Cc, or vice versa, I think the
default should be to move it rather than duplicating it. I can't see
any benefit to having one address in two recipient fields.
-s
