Re: Creating NSTableView programmatically
Re: Creating NSTableView programmatically
- Subject: Re: Creating NSTableView programmatically
- From: Eric Matecki <email@hidden>
- Date: Wed, 20 Dec 2017 10:23:25 +0100
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 (email@hidden)
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:
This email sent to email@hidden