Re: Table selection and bindings

[John Brownie]

OK, that makes sense. Tracing through, I do have a reloadData call, so 
I'll ensure that the selection gets maintained after that.


Yes, there is a mixture of data source and bindings, with the table view 
relying on data source and a bit of KVO, while the inspector relies on 
bindings. Things get rather messy with both the document window and the 
inspector panel having tabbed interfaces, meaning that I keep having to 
check which tab is active in order to activate the appropriate views. It 
may well be that I could do it all with bindings, but, with it all 
working (more or less), I don't want to break it. When I get that far in 
the Swift rewrite, then I can poke at it some more in the hope of making 
it cleaner.


Hopefully all will be well, so thanks for the pointers.

John

Quincey Morris 
14 February 2017 at 20:45

+1 what Keary said.

But there’s another question, which is why your selection is changing 
at all when you edit the object it represents. One possibility is that 
you’re invoking a reloadData on the table view when updating your 
model. If you do that, you must also re-establish the desired 
selection after the reload. Or, if you’re simply replacing the entire 
underlying array with a new instance that contains the modified 
object, the table view might treat that as a reload, depending on how 
your table view content is connected to your data model.


So, I think you are probably doing something “incorrectly”, in the 
sense that you need a lighter hand on the model update, or you need an 
extra step at the end of the update. Currently, it sounds like you are 
effectively but unintentionally clearing the selection 
programmatically, leading to the situation Keary describes.


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/john_brownie%40sil.org

This email sent to john_brow...@sil.org
Keary Suska 
14 February 2017 at 19:25

If you are otherwise getting delegate calls when you manually (i.e. 
NOT programmatically) change the selection, then you are running into 
the situations where notifications are not sent when programmatic 
selection changes are made. The only way around this is to watch 
directly for selection changes, which you may be able to accomplish 
either by observing selectedRowIndexes of NSTableView or 
selectionIndex(es) of an NSArrayController that the table view is bond to.


HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/john_brownie%40sil.org

This email sent to john_brow...@sil.org


--
John Brownie
In Finland on furlough from SIL Papua New Guinea
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Quincey Morris]

On Feb 14, 2017, at 09:25 , Keary Suska  wrote:
> 
>> On Feb 14, 2017, at 8:37 AM, John Brownie > > wrote:
>> 
>> Am I doing things incorrectly, or is there something that I can do to ensure 
>> that the change to the underlying array shown by the table triggers a 
>> selection change?
> 
> If you are otherwise getting delegate calls when you manually (i.e. NOT 
> programmatically) change the selection, then you are running into the 
> situations where notifications are not sent when programmatic selection 
> changes are made.

+1 what Keary said.

But there’s another question, which is why your selection is changing at all 
when you edit the object it represents. One possibility is that you’re invoking 
a reloadData on the table view when updating your model. If you do that, you 
must also re-establish the desired selection after the reload. Or, if you’re 
simply replacing the entire underlying array with a new instance that contains 
the modified object, the table view might treat that as a reload, depending on 
how your table view content is connected to your data model.

So, I think you are probably doing something “incorrectly”, in the sense that 
you need a lighter hand on the model update, or you need an extra step at the 
end of the update. Currently, it sounds like you are effectively but 
unintentionally clearing the selection programmatically, leading to the 
situation Keary describes.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Keary Suska]

> On Feb 14, 2017, at 8:37 AM, John Brownie  wrote:
> 
> I have an NSTableView in a document window, and a utility window which 
> functions as an inspector, so its content is bound to the selected object in 
> the table in the document window. Everything seems fine, but there is a place 
> which doesn't function as I expect.
> 
> In the inspector, I can change the display name of the object, which makes 
> the table drop its selection, so that nothing is selected any more. All OK, 
> but the tableViewSelectionDidChange: delegate method isn't called in this 
> instance. In a way, I can see that it's not the user changing the selection, 
> but the problem becomes that now the inspector is still pointed at an object, 
> but there's no selection, and the logic goes badly wrong.
> 
> Am I doing things incorrectly, or is there something that I can do to ensure 
> that the change to the underlying array shown by the table triggers a 
> selection change?

If you are otherwise getting delegate calls when you manually (i.e. NOT 
programmatically) change the selection, then you are running into the 
situations where notifications are not sent when programmatic selection changes 
are made. The only way around this is to watch directly for selection changes, 
which you may be able to accomplish either by observing selectedRowIndexes of 
NSTableView or selectionIndex(es) of an NSArrayController that the table view 
is bond to.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table selection and bindings

[Steve Mills]

On Feb 14, 2017, at 09:38 AM, John Brownie  wrote:

I have an NSTableView in a document window, and a utility window which 
functions as an inspector, so its content is bound to the selected 
object in the table in the document window. Everything seems fine, but 
there is a place which doesn't function as I expect.


In the inspector, I can change the display name of the object, which 
makes the table drop its selection, so that nothing is selected any 
more. All OK, but the tableViewSelectionDidChange: delegate method isn't 
called in this instance. In a way, I can see that it's not the user 
changing the selection, but the problem becomes that now the inspector 
is still pointed at an object, but there's no selection, and the logic 
goes badly wrong.


Am I doing things incorrectly, or is there something that I can do to 
ensure that the change to the underlying array shown by the table 
triggers a selection change?


Do you have an NSArrayController in the mix somewhere? I think the usual way to hook this 
up is to bind to an NSArrayController, Controller Key "selection". It's kinda 
hard to offer much more help without knowing your exact setup. You mention using 
bindings, but also mention the tableViewSelectionDidChange method. Either you connect 
everything with bindings and it works automatically, or you look for changes via the 
delegate and reflect them in your inspector manually.

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Table selection and bindings

[John Brownie]

I have an NSTableView in a document window, and a utility window which 
functions as an inspector, so its content is bound to the selected 
object in the table in the document window. Everything seems fine, but 
there is a place which doesn't function as I expect.


In the inspector, I can change the display name of the object, which 
makes the table drop its selection, so that nothing is selected any 
more. All OK, but the tableViewSelectionDidChange: delegate method isn't 
called in this instance. In a way, I can see that it's not the user 
changing the selection, but the problem becomes that now the inspector 
is still pointed at an object, but there's no selection, and the logic 
goes badly wrong.


Am I doing things incorrectly, or is there something that I can do to 
ensure that the change to the underlying array shown by the table 
triggers a selection change?

--
John Brownie
In Finland on furlough from SIL Papua New Guinea
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com