Hi,

Richard, I also reply to your msg here to avoid too much redundancy.
Thanks for your efforts.

My project is based on what I believe is an official sample from Apple,
which Richard Charles posted as an attachment to his msg from 12/12/2017.
The sole purpose of my project is to learn how bindings works, it has no 
practical application per se.
I just converted it from NIB based to code generated UI, as I'll have to create 
GUIs procedurally in the near future.
NIBs are all well if your app is something very static, but I can't see how it 
can handle very dynamic stuff,
with data structures you don't event know at the time you write your code.
It may be possible, because...
yes, I'm a beginner with Cocoa/obj-c, that's why I want to learn the 
'best'/'modern' way to use it,
as a lot of the available documentation (the ones I found) is outdated...

But sooner or later you'll have to port your software to another OS, no more 
NIBs.
At least code, while cumbersome, states everything that happens. No magic 
happening behind the scene.
Also code is much easier to version/fix conflicts.
I wonder how IB manages conflicts when merging your code back to the main branch (I didn't try it, I'm not yet that advanced with my exploration of Cocoa app writing... may Apple came out with some clever trick...)

When I select a row in a NSTableView, that selection doesn't "make it" all the 
way to update the controller...

I masochistically downloaded your project, and I think it’s a perfect example 
of why not to do this. There is so much glue code
that it's impossible to tell whether your code is any more than locally correct 
(that is, beyond whether each line of code does
what it purports to do). But all that aside…

— I think it’s a tragic mistake to subclass a NSArrayController. The class is a 
largely inscrutable black box of glue code, and
any code that you add is thrown into the black hole. (I admit this is only an 
opinion. Others may love this kind of self-inflicted
pain.)

— I think it’s *probably* a mistake to use NSArrayControllers *at all* in this 
project, where you’re trying to implement a
specific UI. A NSArrayController is a generalized collection of behaviors 
intended to be used to support a large generality of UI
designs in a NIB file. That level of generality isn’t necessary when you’re 
writing UI code directly, without using NIBs. It’s the
equivalent of using a dictionary with string keys to represent properties, 
instead of declaring the actual properties you want.
The original code used all the same three array controllers, with the exact 
same subclassing of the target's one.

— Your actual problem is that selection doesn’t work because you didn’t connect 
up the right pieces to make it work. For example,
I fixed it for the first table by adding one line of code in the “buildGUI” 
method:

[combatantsTable bind: @"content"  toObject: self.combatantsController  withKeyPath: 
@"arrangedObjects"  options: 0]; //
existing code
[combatantsTable bind: @"selectionIndexes" toObject: self.combatantsController 
withKeyPath: @"selectionIndexes" options: 0]; //
added code
So, where is this documented ?
Finding documentation is the biggest problem I face.
Reference docs are easy to find, but
(https://developer.apple.com/documentation/appkit/nsarraycontroller/1529908-selectionindexes?language=objc)
""""
selectionIndexes
        An index set containing the indexes of the receiver’s currently 
selected objects in the content array
Declaration
        @property(readonly, copy) NSIndexSet *selectionIndexes;
Discussion
        This property is observable using key-value observing.
"""
is of limited use... and it explicitly states KV-observable, not KV-coding 
compliant...

In the sample I have, I can't find any binding involving "selectionIndexes", 
neither in the code nor in the NIB.
It still works without them.
Or, more precisely, without them being *explicitly* bound somewhere, and that's 
the kind of magic I hate.
How should someone convert this to another API ?

So I can change a readonly property thru bindings ?
Whats the use of readonly if it's so easy to change ?
I guess this is just some more obj-c mystery that I'll eventually figure out...

Anyway, it works, so I'm somewhat happy...
Somewhat, because my goal was to understand how bindings work...
While it is logical to bind the selectionIndexes, I don't understand why it is 
readonly...
This readonly-ness is probably why I didn't even consider binding something to 
it,
it was just a 'source' of information in my mind, not a 'destination'.

IOW, the array controller doesn’t know what the current selection is unless you 
tell it. I didn’t try to fix any of the other
tables, but presumably they have the same problem.
Yes, they also work now.

>>     printf("Targets::ArrangeObject()\n”);
> This smells like C++ which is okay but kind of looks like you need more 
practice with Objective-C.
Yes, I'm coming from a C++ background.
But in this precise case, I just dislike all the noise NSLog() adds to my 
'trace' messages...

>>     /*
>>      Create and return an array of all the combatants that are not selected
>>      */

> Oh dear, why are you doing this? The method arrangeObjects: returns an array 
containing objects filtered using the
> receiver's filter predicate and sorted according to the receiver’s 
sortDescriptors. This includes the selection.
> By excluding the selection you have changed the semantics of 
-[NSArrayController arrangeObjects:] for apparently no good reason.
This comes straight from Malcolm Crawford's sample code...
Maybe these predicates/descriptors weren't able to do this is 2007 ? (or 
weren't even available at all ?)
This again shows the plague of outdated documentation/sample code.
I'll look into these predicates/sortdescriptors next.

Thanks to both of you,
Eric M.

Merry X-Mas and a Happy New Year !

--
Keep intel OUTSIDE my Mac !
Hiii !!! I can see Intel chips creeping around my G5 !

Eric M.
_______________________________________________

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

Reply via email to