Programmatic table selection not firing -tableViewSelectionDidChange:

[Luke]

I have noticed that programmatic selection changes on a CPTableView
don't cause a tableViewSelectionDidChange: message to the delegate.
This message does get sent if you click on a table (row).

I should probably go try this in Cocoa to be sure, but I think the
delegate should get notified even if some other part of the code
changes the selection programmatically.

[Francisco Tolmasky]

I believe this is by design. If I remember correctly I tried this in
Cocoa and it also behaved this way, we should of course double check
though.

[Luke]

OK, I just wrote a quick test:
files.me.com/luke_e/2f1pau

Cocoa _does_ send a tableViewSelectionDidChange notification (and of
course the related call to the delegate if the method is implemented),
when the selection is changed programmatically.

[Randy Luecke]

I fixed it in my branch. Whenever my other fixes and feature
implementations get merged it should be included.

[Luke]

Thanks Randy.

How often do your changes normally get merged? I'm wondering whether
to wait, or if I should grab your change now and patch my own
sources.
I could do with trading up to the head again soon - I'm currently
running something that's about a month old, and there are some other
bugs I _think_ are fixed in the head.

[Randy Luecke]

It all depends on when Francisco gets time to merge it in.
Here's a link to my CPTableView.j file
http://github.com/Me1000/cappuccino/blob/6db067c72946e22ba13a795589871187a9d444c4/AppKit/CPTableView.j

I've added support for scrollRowToVisible and scrollColumnToVisible as
well as autoscrolling when you drag outside the bounds of the
tableview and keyboard support.

[Jérôme Denanot]

Also to note that before September tableViewSelectionIsChanging had been used instead of tableViewSelectionDidChange (has been reverted since mid September). So It seems it changed again ?

2009/10/27 Randy Luecke <rclco...@gmail.com>

[Randy Luecke]

Wait, are you saying it changed in Cocoa... or am I misunderstanding?

On Oct 27, 11:09 am, Jérôme Denanot <jdena...@gmail.com> wrote:
> Also to note that before September tableViewSelectionIsChanging had been
> used instead of tableViewSelectionDidChange (has been reverted since mid
> September). So It seems it changed again ?
>

> 2009/10/27 Randy Luecke <rclconce...@gmail.com>

>
>
>
>
>
> > It all depends on when Francisco gets time to merge it in.
> > Here's a link to my CPTableView.j file
>

> >http://github.com/Me1000/cappuccino/blob/6db067c72946e22ba13a79558987...

[Luke]

I'm curious what this means too - obviously my code is currently in
the twilight zone caught between two worlds ;-)

The Cocoa docs for NSTableViewSelectionIsChangingNotification says:
Posted as an NSTableView object's selection changes (while the mouse
button is still down). The notification object is the table view whose
selection is changing. This notification does not contain a userInfo
dictionary.

and the related table delegate method (-tableViewSelectionIsChanging:)
has this note:
Informs the delegate that the table view’s selection is in the process
of changing (typically because the user is dragging the mouse across a
number of rows).

These two are definitely related to the user's mousing activities, and
not are not a notification that the table selection DID change (by
whatever means, including programmatically).

I have code that needs to respond to changes in selection however that
occurs, and its natural (and in keeping with common patterns) to hook
this off the notification that this has occurred, rather than rolling
my own parallel update mechanism and sprinkling calls to an update
method around places that induce a change.

[Jérôme Denanot]

Sorry if it leads to misleading, I was just asking whether the tableView code changed again since september, since I don't remember having seen changes when I looked at it recently.

If I remember I check for the avaibility of both in CP2javaWS (was done in order for it to work with both the old table view and the new one from this summer), so it should be fine.

The various delegate methods can both be useful, it depends. It seems usual in Cocoa to inform other related components that we will do something, and then notifying them again when the job is done.

About table selection, relying on DidChange seems more reliable for most cases, however the table view could fire the two notifications (at appropriate time in the cycle). It is really a minor issue, since we can define a category for now if needed.

2009/10/27 Randy Luecke <rclco...@gmail.com>

[Randy Luecke]

oh,
I don't believe there have been many changes to the tableview in the
master branch since the tableview got merged in.

On Oct 27, 7:00 pm, Jérôme Denanot <jdena...@gmail.com> wrote:
> Sorry if it leads to misleading, I was just asking whether the tableView
> code changed again since september, since I don't remember having seen
> changes when I looked at it recently.
> If I remember I check for the avaibility of both in CP2javaWS (was done in
> order for it to work with both the old table view and the new one from this
> summer), so it should be fine.
>
> The various delegate methods can both be useful, it depends. It seems usual
> in Cocoa to inform other related components that we will do something, and
> then notifying them again when the job is done.
> About table selection, relying on DidChange seems more reliable for most
> cases, however the table view could fire the two notifications (at
> appropriate time in the cycle). It is really a minor issue, since we can
> define a category for now if needed.
>

> 2009/10/27 Randy Luecke <rclconce...@gmail.com>