subject:"Creating NSTableView programmatically"

Re: Creating NSTableView programmatically

2017-12-20 Thread Quincey Morris

On Dec 20, 2017, at 18:55 , Rob Petrovec  wrote:
> 
> Not for nothin', but I don’t think bindings have died.

So, let me respond jointly to all of the comments similar to this.

Of course bindings haven’t “died”, in the sense that no one *uses* them any 
more. My point was that bindings, as a conceptual software design paradigm or 
implementation framework for the general presentation or handling of data, 
don’t have much significance any more. We don’t sit down and *design* bindings 
for our apps, typically. We just bind things together when their values need to 
track each other. This should be understood as a simplification, not a denial 
that some people still get into them more deeply.

Consider also that there have been no functional improvements made to bindings 
since 10.5 (at least, I can’t think of even one), and that bindings were *not* 
taken over to iOS in 2008.

Of course, this is no rejection of KVO, which remains essential and creatively 
productive, despite being mechanically outdated.
___

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: Creating NSTableView programmatically

2017-12-20 Thread Rob Petrovec

Not for nothin', but I don’t think bindings have died. They are still supported 
and used all over the OS.  I use them all the time in my code too.  They are 
very useful.  Bindings are built onto of KVO, which is a fundamental technology.

—Rob


> On Dec 20, 2017, at 3:40 PM, Richard Charles  wrote:
> 
> 
>> On Dec 20, 2017, at 3:23 AM, Quincey Morris 
>>  wrote:
>> 
>> In effect, the whole thing with bindings died at 10.5, except for the part 
>> where they were used within IB to hook up specific controls to specific 
>> properties. That part is really all we use today.
> 
> It does seem like bindings died but I have found them very useful.
> 
> https://stackoverflow.com/questions/1169097/can-you-manually-implement-cocoa-bindings
> 
> https://www.tomdalling.com/blog/cocoa/implementing-your-own-cocoa-bindings/
> 
>> On Dec 20, 2017, at 3:07 PM, Charles Srstka  wrote:
>> 
>> I doubt I would have gone to the trouble of making it do that if I’d had to 
>> write the glue code manually.
> 
> For me it was a trade off. Do I invest time in learning bindings or become 
> really good at writing glue code. I suppose it would have worked either way 
> but for some reason I choose bindings.
> 
> --Richard Charles
> 
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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: Creating NSTableView programmatically

2017-12-20 Thread Richard Charles

> On Dec 20, 2017, at 3:23 AM, Quincey Morris 
>  wrote:
> 
> In effect, the whole thing with bindings died at 10.5, except for the part 
> where they were used within IB to hook up specific controls to specific 
> properties. That part is really all we use today.

It does seem like bindings died but I have found them very useful.

https://stackoverflow.com/questions/1169097/can-you-manually-implement-cocoa-bindings

https://www.tomdalling.com/blog/cocoa/implementing-your-own-cocoa-bindings/

> On Dec 20, 2017, at 3:07 PM, Charles Srstka  wrote:
> 
> I doubt I would have gone to the trouble of making it do that if I’d had to 
> write the glue code manually.

For me it was a trade off. Do I invest time in learning bindings or become 
really good at writing glue code. I suppose it would have worked either way but 
for some reason I choose bindings.

--Richard Charles

___

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: Creating NSTableView programmatically

2017-12-20 Thread Charles Srstka

> On Dec 20, 2017, at 4:23 AM, Quincey Morris 
>  wrote:
> 
>> The original code used all the same three array controllers, with the exact 
>> same subclassing of the target's one.
> 
> This is where I take the fifth. 
> 
> When bindings were introduced, back in 10.3 or 10.4, then refined in 10.5, it 
> looked very much like Apple was trying to sell a sort of data-manipulation 
> “language” constructed out of bindings and NS…Controller classes. While this 
> worked great for pushing glue code out of .m source files and into .nib files 
> (this predated .xib files), it’s was too general, too inscrutable and too 
> clumsy to have much wider appeal. In effect, the whole thing with bindings 
> died at 10.5, except for the part where they were used within IB to hook up 
> specific controls to specific properties. That part is really all we use 
> today.

That’s going a little far, isn’t it? I still find bindings/KVO useful for a lot 
of cases where I want to keep things synced. For example, in Pacifist I have a 
main outline view, and a search results table on the side (currently in a 
drawer, although that’s changing in the currently-under-development Swift 
rewrite). The selected item in the search results and in the main outline view 
should always be the same, and I do that by setting things up, via a system of 
computed properties and keyPathsForValuesAffecting methods, so that the 
table’s selectionIndexes and the outline’s selectionIndexPaths are both 
essentially backed by the same underlying property. The result is that not only 
does it update the selection in the outline view when you change the selection 
in the search results, as you’d expect, but it also manages to update the 
selection in the *search results* if you select an item in the main outline 
view that happens to also be a search result. A big deal? No, but it’s one of 
those little details that makes an old Mac geek like me smile. ;-) I doubt I 
would have gone to the trouble of making it do that if I’d had to write the 
glue code manually.

Charles
___

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: Creating NSTableView programmatically

2017-12-20 Thread Richard Charles

> On Dec 20, 2017, at 2:23 AM, Eric Matecki  wrote:
> 
> 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.

It looks like you have taken your project from Malcolm Crawford's “Combatants” 
sample code. If I remember correctly Malcolm did work for Apple and was a one 
of the public experts on Cocoa bindings at the time. This sample code however 
is of his own making and did not come from Apple. In this sample code he does 
subclass NSArrayController and overrides the behavior of arrangeObjects: to 
exclude the selection (much to my surprise). This is very advanced stuff you 
are delving into.

Malcolm's sample code that really helped me was "Graphics Bindings” which was 
aligned with a major project I was working on. On this project I actually ended 
up subclassing NSArrayController because I could see no way around it but as 
Quincey Morris has indicated it was a very painful process.

But before delving into programmatic Cocoa bindings I must have spent a year 
with Aaron Hillegass in Cocoa Programming for Mac OS X. If you have a C++ 
background, Aaron will take you by the hand and lead you along a correct path. 
My current major project is for macOS and requires interoperability with C++ so 
I have yet to jump on the Swift or iOS bandwagon. Note that Cocoa Programming 
by Hillegass uses the Swift language starting with the 5th Edition and up.

I actually use OS X v10.9 documentation every day. It is old style, accurate, 
extremely usable, searchable, compact, and works well inside a web browser. I 
absolutely detest the new style documentation and find it almost unusable. 
Anyway that is what I do for documentation.

Good luck with your project.

--Richard Charles

___

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: Creating NSTableView programmatically

2017-12-20 Thread Quincey Morris

On Dec 20, 2017, at 01:23 , Eric Matecki  wrote:
> 
> The sole purpose of my project is to learn how bindings works, it has no 
> practical application per se.

Bindings exist to support the use of NIB-based UI behavior. All bindings work 
the same way, in the sense that they tie together the values of properties in 
each of two objects, so that a change in one appears as a change in the other, 
in either direction. This sort of equivalent to mutual KVO-observation with 
mutual updating, except that only the property in the target object (the one 
bound *to*) is actually a property in the KVC sense. The “property” in the 
source object (the one bound *from*) is a notional identifier that may or may 
not correspond to a true property of the object.

For example, when binding the content of a NSTextView, you bind the “value” 
binding to a NSString property of some other object. There is no “value” 
property, the binding name is meaningful only as a binding name. That means 
that all of the binding names have to be documented somewhere, and that happens 
to be the Cocoa Bindings Reference document, which is a long list of classes 
and the bindings that have been defined to exist in each.

That tells you what any given binding is for (provided you can understand what 
the documentation says, which is more of a problem than it ought to be), but it 
doesn’t tell you when you should use the binding. That you kinda figure out by 
trial and error. You can figure out when you need to use the NSTextView “value” 
binding, for example, and you can probably figure out the font and point size 
bindings, but go look at the bindings for NSPopUpButton and you’re gonna be 
scratching your head.

> I wonder how IB manages conflicts when merging your code back to the main 
> branch

Ever since version  of Xcode, IB manages this by using a XIB 
file as the source code of a compiled NIB file, and a XIB file is text in some 
kind of XML format. That means it can be diff’ed and merged, hence managed via 
source control. You can see this yourself by switching the assistant editor to 
show the version history, and the main view will switch from a graphic canvas 
to a long, long text description.

> The original code used all the same three array controllers, with the exact 
> same subclassing of the target's one.

This is where I take the fifth. 

When bindings were introduced, back in 10.3 or 10.4, then refined in 10.5, it 
looked very much like Apple was trying to sell a sort of data-manipulation 
“language” constructed out of bindings and NS…Controller classes. While this 
worked great for pushing glue code out of .m source files and into .nib files 
(this predated .xib files), it’s was too general, too inscrutable and too 
clumsy to have much wider appeal. In effect, the whole thing with bindings died 
at 10.5, except for the part where they were used within IB to hook up specific 
controls to specific properties. That part is really all we use today.

This particular sample app comes from about the 10.4 era, ideologically if not 
actually. It illustrates how to do things no one really wanted to do after 
about 2005. Your current project is archeology, not development.

> 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.

Well, it’s not quite magic, but nearly. This *isn’t* documented anywhere, or 
(if it was) it was documented in an old version of the Table View Programming 
Guide that no longer exists.

In a NSCell-based table view (the only kind at the time this sample app was 
written), when you bind table columns to a property of an array controller, 
something (the table view? the NIB-loading mechanism? IDK exactly) notices that 
the table view is missing its “content” binding and binds it to the array 
controller. Then it also binds the “selectionIndexes” binding. Most people 
don’t explicitly know that, because it just works and so they don’t have to 
think about it. It’s only when something is arranged differently (like using a 
table view without an array controller, or … what you’re doing) that anyone 
notices.

This is one reason why we generally use XIB/NIB files instead of code — it 
allows us to let IB to worry about the magic, so we don’t have to. (FWIW, stuff 
like this is one reason why IB is huge, slow and buggy. Every tiny detail of 
every old NIB behavior in every macOS version has to be religiously preserved 
in IB.)

>   @property(readonly, copy) NSIndexSet *selectionIndexes;

> So I can change a readonly property thru bindings ?

It’s … um … not readonly. But the setter method looks like this:

> - (BOOL)setSelectionIndexes:(NSIndexSet *)indexes;

which is to say, it’s not exactly a setter because it returns a value. If, 
however, you squint and ignore the return value, it works just fine as a 
s

Re: Creating NSTableView programmatically

2017-12-20 Thread Eric Matecki

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 ca

Re: Creating NSTableView programmatically

2017-12-19 Thread Richard Charles


> Eric Matecki - Combatants Project on GitHub
> 
> File Combatants.m
> 
> /*
>  Create and return an array of all the combatants that are not selected
>  */
> - (NSArray *) arrangeObjects: (NSArray*)iObjectsToArrange
> {
> printf("Targets::ArrangeObject()\n”);

This smells like C++ which is okay but kind of looks like you need more 
practice with Objective-C.

> unsigned int  scCount = (unsigned int)[selectedCombatants  count];
> 
> if( (scCount == 0)  ||  (selectedCombatants == nil) )
> // second test effectively redundant, but...
> {
> printf("no objects to arrange\n");
> return  [super  arrangeObjects: iObjectsToArrange];   
> }
> 
> /*
>  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.

> NSMutableArray*  arrangedObjects = [NSMutableArray  arrayWithCapacity: 
> [iObjectsToArrange  count] - scCount];
> 
> NSEnumerator*  objectEnumerator = [iObjectsToArrange  objectEnumerator];
> id  item;
> while( item = [objectEnumerator nextObject] )
> {
> if (![selectedCombatants  containsObject: item])
> {
> printf("%s\n", [[item  name]  UTF8String]);
> [arrangedObjects  addObject: item];
> }
> }
> return  [super  arrangeObjects: arrangedObjects];
> }

I agree with Quincey Morris, subclassing NSArrayController is generally a bad 
idea. It is apparent you need a lot more practice with Objective-C and the 
Cocoa frameworks before you should ever need to do something like this.

A great place to start is with Cocoa Programming for Mac OS X (4th Edition) by 
Aaron Hillegass if you are doing Objective-C. One of the things Aaron tells you 
right up front is “Beginning Cocoa programmers are often eager to create 
subclasses of NSString and NSMutableArray. Don’t. Stylish Objective-C 
programmers almost never do. Instead, they use NSString and NSMutableArray as 
parts of larger objects, a technique known as composition.”

I hope this helps.

--Richard Charles

___

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: Creating NSTableView programmatically

2017-12-19 Thread Quincey Morris

On Dec 19, 2017, at 02:24 , Eric Matecki  wrote:
> 
> 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.

— 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

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.

___

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: Creating NSTableView programmatically

2017-12-19 Thread Eric Matecki


On 19/12/2017 11:24, Eric Matecki wrote:

Hello all,

No I didn't abandon all hope, I was just busy :)

Thanks to all the replies, I got a lot further, but still didn't reach my 
destination...

Now I have a nice window, looking almost exactly like the NIB created one.

Most things works, except the most fundamental one.
When I select a row in a NSTableView, that selection doesn't "make it" all the 
way to update the controller...

The code/project is now available here : 
https://gitlab.com/CocoaMusings/Combatants

Any suggestion(s) is appreciated.

Eric M.


I just noticed that the preview in gilab doubled-up some dashes in front of 
some methods.
I checked by cloning the repo in another folder, and they aren't there...
Just a display error from gitlab.

--
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

Re: Creating NSTableView programmatically

2017-12-19 Thread Eric Matecki


Hello all,

No I didn't abandon all hope, I was just busy :)

Thanks to all the replies, I got a lot further, but still didn't reach my 
destination...

Now I have a nice window, looking almost exactly like the NIB created one.

Most things works, except the most fundamental one.
When I select a row in a NSTableView, that selection doesn't "make it" all the 
way to update the controller...

The code/project is now available here : 
https://gitlab.com/CocoaMusings/Combatants

Any suggestion(s) is appreciated.

Eric M.

--
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

Re: Creating NSTableView programmatically

2017-12-14 Thread corbin dunn



> On Dec 12, 2017, at 2:12 AM, Eric Matecki  wrote:
> 
> Hi,
> 
> On 11/12/2017 20:10, Quincey Morris wrote:
>>> I made my own text field class according to this (in NSTableCellView's doc) 
>>> :
>> 
>> I think you’re still kinda Doing It Wrong™. The standard (and, I believe, 
>> recommended) way to do this is to create an instance of
>> NSTableCellView, which has the “objectValue” property, along with other 
>> potentially useful behaviors for cell views (such as
>> identifiers that allow the NSTableView to cache and manage cell views).
> 
> I know it's wrong, or at least bad, but NSTextView and NSButton are the 
> controls I kind of master right now...
> I really don't need a textview, as I'm just trying to reproduce the 
> "Combattant" example.
> I still can't get the names to display with NSTableCellView.
> 
> Here (at the bottom of the page) :
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
> it says :
> """
> When you make the connection to the table view’s Content binding, the 
> objectValue property of the NSTableViewCell used as the cell for the table 
> column is configured such that for each item in the model array, the table 
> updates the objectValue property to the current row’s Person object
> 1) Select the text field in the table column cell and create the binding.
> All bindings of subviews in the cell are made to the objectValue.
> Configure the textField instance’s value binding.
> 
> Binding field | Value
> ---
> Bind to:  | Table Cell View
> Model key path| objectValue.name
> """
> 
> So I have this in my NSTableView's delegate, which is my interpretation of 
> the above :
> 
> - (NSView *)tableView:(NSTableView *)tableView
>   viewForTableColumn:(NSTableColumn *)tableColumn
>  row:(NSInteger)row
> {
> #if 0  // this shows the names
> 
>cTextView*  view = [[cTextView  alloc]  init]; // cTextView is my custom 
> NSTextView with just an added objectValue property
>[view  bind: @"value"  toObject: tableView  withKeyPath: 
> @"objectValue.name"  options: 0];  // wrong, but works
>//[view  bind: @"value"  toObject: view  withKeyPath: @"objectValue.name"  
> options: 0]; // right, works
> 
> #else // this doesn't show the names
> 
>NSTableCellView*  view = [[NSTableCellView  alloc]  init];
>//[[view  textField]  setBackgroundColor: [NSColor  redColor]]; // just to 
> be sure to see it when empty... nada
>//[[view  textField]  bind: @"value"  toObject: tableView  withKeyPath: 
> @"objectValue.name"  options: 0]; // wrong, doesn't work
>[[view  textField]  bind: @"value"  toObject: view  withKeyPath: 
> @"objectValue.name"  options: 0]; // right?, but doesn't work

^ This is correct, but the piece you are missing is somehow providing the 
objectValue for the resulting tableCellView. 

NSTableView sets the objectValue to the result from the table’s content 
binding. It does this on the result you return from the above method. However, 
I recommend just implementing tableView:objectValueForTableColumn:row: in your 
delegate and returning something. The “something” you are turning has to be an 
object that has a “name” property (based on your binding). You could just bind 
it to “objectValue” and return a (cached) string.

corbin

> 
> #endif
>return  view;
> }
> 
> Note that I bind the NSTextView to tableView, while the doc says "the 
> objectValue property of the NSTableViewCell", not of the tableview... but it 
> works, and I don't understand why... I don't like it when I don't understand 
> what's happening.
> It also works when binding to the view, which is expected (I first bound it 
> to tableView by mistake...).
> It's still weird (to me) to bind an object's binding to one of it's own 
> properties.
> I guess it's more or less by chance that it displays the names, and that some 
> changes in my model won't get correctly propagated...
> 
> In the case of NSTableCellView, neither binding works... I don't get any 
> exception or crash, but nothing is displayed inside my table view (although 
> it's size suggests the four rows are there).
> But setting the backgroud of the textfield to red doesn't show any red on the 
> screen...
> (Trying to the set the cell's background gives me a "may not respond to 
> message" warning, and obviously nothing gets red on the screen).
> 
> Something in the "big scheme of things" escapes me, and Apple's doc was not 
> very helpful until now.
> 
>> In a very unusual or complex case, you might subclass NSTableCellView to add 
>> properties or behaviors to it, but it’s normally not
>> necessary. Custom properties, for example, can be carried around by the 
>> object referred to by “objectValue”, and custom behaviors
>> can sometimes be implemented as part of the delegate.
>> 
>> Instead of using a cell view other than a NSTableCellView or subclass, it’s 
>> usu

Re: Creating NSTableView programmatically

2017-12-12 Thread Richard Charles


> On Dec 12, 2017, at 2:40 PM, Jonathan Mitchell  wrote:
> 
>> On 12 Dec 2017, at 19:56, Richard Charles  wrote:
>> 
>> I always assumed the reason bindings never came over to iOS was they 
>> consumed too much cpu power and were too difficult to understand. It seems 
>> evident that 10 or 20 years from now Apple anticipates the bulk of it 
>> programmers coming out of school will use iPads with the new style 
>> documentation. Cocoa bindings do not fit very well into this picture.
> I am not sure if stringent power concerns were the overriding factor for 
> excluding bindings from iOS. 
> Bindings are driven by observations, which do exist on iOS.

I stand somewhat corrected, I did not know KVO was available on iOS.

> Bindings are actually a fairly essential technology for medium to large scale 
> data driven macOS applications.
> Trying to manually glue hundreds of controls and data paths together quickly 
> becomes a major development obstacle.

Amen to that!

--Richard Charles

___

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: Creating NSTableView programmatically

2017-12-12 Thread Jonathan Mitchell

> On 12 Dec 2017, at 19:56, Richard Charles  wrote:
> 
> I always assumed the reason bindings never came over to iOS was they consumed 
> too much cpu power and were too difficult to understand. It seems evident 
> that 10 or 20 years from now Apple anticipates the bulk of it programmers 
> coming out of school will use iPads with the new style documentation. Cocoa 
> bindings do not fit very well into this picture.
I am not sure if stringent power concerns were the overriding factor for 
excluding bindings from iOS. 
Bindings are driven by observations, which do exist on iOS. 
I think that some developers use reactive frameworks such as ReactiveCocoa to 
achieve UI binding on IOS - but I am not sure that would count as a 
simplification.

Cocoa bindings are okay though they lack flexibility and features when compared 
to the likes of WPF bindings.
WPF bindings are just about as tricky to get right - though the use of a GC 
makes life generally easier in a managed world.

Bindings are actually a fairly essential technology for medium to large scale 
data driven macOS applications.
Trying to manually glue hundreds of controls and data paths together quickly 
becomes a major development obstacle.

J

___

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: Creating NSTableView programmatically

2017-12-12 Thread Richard Charles

> On Dec 12, 2017, at 12:08 PM, Quincey Morris 
>  wrote:
> 
> I don’t think bindings are fading away. They can’t, while they’re the only 
> way to connect UI elements without custom glue code. However, the design is 
> ancient (IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, 
> and really nothing has changed since then).

It is the documentation of bindings that is fading away and if you are an iOS 
programmer then bindings are irrelevant. Malcolm Crawford had an excellent 
resource on the web for understanding bindings (Cocoa Bindings Examples and 
Hints) but it has disappeared. Malcolm Crawford made his last post to cocoa-dev 
in 2012 and so time marches on.

> What has fallen away (because it never really got off the ground) was the use 
> of *custom* bindings, in part because no one could understand what to do, and 
> because they really needed the IB customization features introduced in Xcode 
> 3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).

Custom programmatic bindings (not integrated with IB) work great but it is 
daunting to figure this out. So I agree.

> In modern terms, bindings are a horrible hack, and that’s why (I assume) they 
> were never taken over to iOS.

I always assumed the reason bindings never came over to iOS was they consumed 
too much cpu power and were too difficult to understand. It seems evident that 
10 or 20 years from now Apple anticipates the bulk of it programmers coming out 
of school will use iPads with the new style documentation. Cocoa bindings do 
not fit very well into this picture.

--Richard Charles

___

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: Creating NSTableView programmatically

2017-12-12 Thread Quincey Morris

On Dec 12, 2017, at 02:12 , Eric Matecki  wrote:
> 
> In the case of NSTableCellView, neither binding works... I don't get any 
> exception or crash, but nothing is displayed inside my table view (although 
> it's size suggests the four rows are there).

This was a conceptual failure on my part, since I’ve never actually created a 
NSTableCellView manually. The cell view has “imageView" and “textField” 
outlets, but they’re not connected to anything by default, and the cell view 
has no subviews by default. (One or both subviews is present and connected when 
you do this in IB, because IB uses a preconfigured cell view hierarchy.)

If you want to use a text view, you will have to subclass NSTableCellView to 
add a “textView” outlet. or you can use a text field with the existing 
“textField” outlet. Either way, you’ll need to create the text-displaying 
subview, and set the corresponding outlet.

>[view  bind: @"value"  toObject: tableView  withKeyPath: 
> @"objectValue.name"  options: 0];  // wrong, but works

I have no idea why that works, it makes no sense whatever.

You’re still missing some stuff, BTW:

— For proper table view behavior, you really should create the cells by 
invoking "makeView(withIdentifier:owner:)”, so that the table view can manage 
the lifetimes and reusability of the cell views. However, this mechanism is 
intended to work with a NIB for the table cell view. This can either come from 
the table view’s own NIB file (via a private mechanism that IB sets up for you) 
or a freestanding NIB file (which you must register with the table view 
manually). Since you have neither, you will (I guess) need to let the cell 
creation portion of the "makeView(withIdentifier:owner:)” API fail, when a cell 
view isn’t being reused, then create your cell view manually.

Technically, you don’t have to do this, I suppose, but you said you were trying 
to learn what normally goes on, and cell view caching is what normally happens.

— You didn’t embed your table view in a scroll view. 

If it can’t scroll, the table view isn’t much use.

> How do you "ignore" what you don't need in an NSTableCellView ?

As I said, I was confusing two things. Most standard cells created in IB are 
just text, and have no image view.

> And when I add a subview to one, how do I arrange (layout) it's content

The usual ways, which is to say: add layout constraints, or set the frame 
manually if you’re not using autolayout.

> It's still weird (to me) to bind an object's binding to one of it's own 
> properties.

It’s just a special case of a “derived” property. It’s not so unusual for an 
object to observe one of its own properties in order to provide a KVO compliant 
value for another property. Anyway, in this case, it’s conceptually binding to 
a different object (the one referenced by “objectValue”) to get its “name” 
property. The indirection falls out of the division between standard behavior 
and custom behavior that’s built into the table view design.

> Too bad that bindings are fading away

I don’t think bindings are fading away. They can’t, while they’re the only way 
to connect UI elements without custom glue code. However, the design is ancient 
(IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, and really 
nothing has changed since then).

What has fallen away (because it never really got off the ground) was the use 
of *custom* bindings, in part because no one could understand what to do, and 
because they really needed the IB customization features introduced in Xcode 
3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).

In modern terms, bindings are a horrible hack, and that’s why (I assume) they 
were never taken over to iOS.

___

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: Creating NSTableView programmatically

2017-12-12 Thread Eric Matecki


Hi Richard,

thanks for all this reading !
I'll need a day or two to understand everything therein. Even if they aren't 
that long, there are a lot of subtle details :)

Too bad that bindings are fading away, the concept is great, the implementation 
is not so great from skimming thru these pages

Eric M.

On 12/12/2017 14:02, Richard Charles wrote:



On Dec 12, 2017, at 3:12 AM, Eric Matecki  wrote:

It's still weird (to me) to bind an object's binding to one of it's own 
properties.


I have an applicaiton that extensively uses programmatic and custom bindings. 
The following have helped me understanding bindings.


...


==

Bindings are a bit of a mystery especially programmatic bindings. Perhaps 
because iOS does not have bindings, interest in bindings and information about 
bindings appears to be diminishing.

--Richard Charles


--
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

Re: Creating NSTableView programmatically

2017-12-12 Thread Eric Matecki

Hi,

On 11/12/2017 20:10, Quincey Morris wrote:

I made my own text field class according to this (in NSTableCellView's doc) :

I think you’re still kinda Doing It Wrong™. The standard (and, I believe,
recommended) way to do this is to create an instance of
NSTableCellView, which has the “objectValue” property, along with other
potentially useful behaviors for cell views (such as
identifiers that allow the NSTableView to cache and manage cell views).

I know it's wrong, or at least bad, but NSTextView and NSButton are the
controls I kind of master right now...
I really don't need a textview, as I'm just trying to reproduce the
"Combattant" example.
I still can't get the names to display with NSTableCellView.

Here (at the bottom of the page) :
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
it says :
"""
When you make the connection to the table view’s Content binding, the objectValue property of the NSTableViewCell used as the cell
for the table column is configured such that for each item in the model array, the table updates the objectValue property to the
current row’s Person object

1) Select the text field in the table column cell and create the binding.
All bindings of subviews in the cell are made to the objectValue.
Configure the textField instance’s value binding.

Binding field | Value
---
Bind to:| Table Cell View
Model key path | objectValue.name
"""

So I have this in my NSTableView's delegate, which is my interpretation of the
above :

- (NSView *)tableView:(NSTableView *)tableView
viewForTableColumn:(NSTableColumn *)tableColumn
row:(NSInteger)row
{
#if 0 // this shows the names

cTextView* view = [[cTextView alloc] init]; // cTextView is my custom
NSTextView with just an added objectValue property
[view bind: @"value" toObject: tableView withKeyPath:
@"objectValue.name" options: 0]; // wrong, but works
//[view bind: @"value" toObject: view withKeyPath: @"objectValue.name"
options: 0]; // right, works

#else // this doesn't show the names

NSTableCellView* view = [[NSTableCellView alloc] init];
//[[view textField] setBackgroundColor: [NSColor redColor]]; // just to
be sure to see it when empty... nada
//[[view textField] bind: @"value" toObject: tableView withKeyPath:
@"objectValue.name" options: 0]; // wrong, doesn't work
[[view textField] bind: @"value" toObject: view withKeyPath:
@"objectValue.name" options: 0]; // right?, but doesn't work

#endif
return view;
}

Note that I bind the NSTextView to tableView, while the doc says "the objectValue property of the NSTableViewCell", not of the
tableview... but it works, and I don't understand why... I don't like it when I don't understand what's happening.

It also works when binding to the view, which is expected (I first bound it to
tableView by mistake...).
It's still weird (to me) to bind an object's binding to one of it's own
properties.
I guess it's more or less by chance that it displays the names, and that some
changes in my model won't get correctly propagated...

In the case of NSTableCellView, neither binding works... I don't get any exception or crash, but nothing is displayed inside my
table view (although it's size suggests the four rows are there).

But setting the backgroud of the textfield to red doesn't show any red on the
screen...
(Trying to the set the cell's background gives me a "may not respond to message" warning, and obviously nothing gets red on the
screen).

Something in the "big scheme of things" escapes me, and Apple's doc was not
very helpful until now.

In a very unusual or complex case, you might subclass NSTableCellView to add
properties or behaviors to it, but it’s normally not
necessary. Custom properties, for example, can be carried around by the object
referred to by “objectValue”, and custom behaviors
can sometimes be implemented as part of the delegate.

Instead of using a cell view other than a NSTableCellView or subclass, it’s
usual to *add subviews* for things like text fields
and buttons. That separates the behavior of the cell *as a cell* (such as being
cached for the table view) from the view hierarchy
represented by the cell. However, if your cell just needs to contain a text
field, you don’t need to add one yourself,
because NSTableCellView already contains a NSTextField subview that you can
just *use*. It also contains NSImageView subview that
you can use or ignore.

How do you "ignore" what you don't need in an NSTableCellView ?
And when I add a subview to one, how do I arrange (layout) it's content, so it works with the way the 'free' NSTextField and
NSImageView are arranged (which I ignore) ?

NSTableCellView's doc is rather scarce.

Now I can see all the names :)

One reason to use a NSTableCellView instead of a control sum as

Re: Creating NSTableView programmatically

2017-12-11 Thread Charles Srstka

> On Dec 11, 2017, at 4:59 AM, Eric Matecki  wrote:
> 
> 
> Hello,
> 
> I'm trying to implement in Objective-C on macOS *programmatically* the "Real 
> World Example" at the bottom of this page :
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html
>  
> 
> 
> …
> 
> -- 
> Keep intel OUTSIDE my Mac !
> Hiii !!! I can see Intel chips creeping around my G5 !

I dunno, to me it seems that trying to get NSTableView to work right without 
just using a nib is as much of a losing battle as still trying to fight the 
PPC->Intel transition in 2017… ;-)

Charles

___

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: Creating NSTableView programmatically

2017-12-11 Thread Quincey Morris

On Dec 11, 2017, at 10:19 , Alastair Houghton  
wrote:
> 
> NSTableViewCell is the old way to do it, before view-based tables were the 
> norm

In this case, I think “NSTableViewCell” is a typo in the documentation. In the 
following tables, it refers to the binding target as “Table Cell View”, not 
“Table View Cell”. NSCell-based tables did use cell class names with the 
pattern “NS…Cell”, but NSTableViewCell wasn’t one of them AFAIK. (In iOS, of 
course, the equivalent cell view is UITableViewCell, just to keep us on our 
toes.)

On Dec 11, 2017, at 05:53 , Eric Matecki  wrote:
> 
> I made my own text field class according to this (in NSTableCellView's doc) :

I think you’re still kinda Doing It Wrong™. The standard (and, I believe, 
recommended) way to do this is to create an instance of NSTableCellView, which 
has the “objectValue” property, along with other potentially useful behaviors 
for cell views (such as identifiers that allow the NSTableView to cache and 
manage cell views). 

In a very unusual or complex case, you might subclass NSTableCellView to add 
properties or behaviors to it, but it’s normally not necessary. Custom 
properties, for example, can be carried around by the object referred to by 
“objectValue”, and custom behaviors can sometimes be implemented as part of the 
delegate.

Instead of using a cell view other than a NSTableCellView or subclass, it’s 
usual to *add subviews* for things like text fields and buttons. That separates 
the behavior of the cell *as a cell* (such as being cached for the table view) 
from the view hierarchy represented by the cell. However, if your cell just 
needs to contain a text field, you don’t need to add one yourself, because 
NSTableCellView already contains a NSTextField subview that you can just *use*. 
It also contains NSImageView subview that you can use or ignore.

> Now I can see all the names :)

One reason to use a NSTableCellView instead of a control sum as a text field is 
that the cell view’s size is *forced* to the dimensions required by the table 
view row. That means you have no control of the placement of the contents 
relative to the row. For a text field, for example, you have no direct way of 
controlling the margins surrounding the text. This approach also limits the use 
of autolayout, which may or may not be an issue in your project.

> - (NSView *)tableView:(NSTableView *)tableView  
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
>NSTextView*  view = [[NSTextView  alloc]  init];
> …

You say “text field” everywhere, but you actually create a text view. I don’t 
get a sense of which one you really want to use, but using a separate 
NSTextView for each row of the table could end badly, and subclassing 
NSTextView is probably a code smell.

___

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: Creating NSTableView programmatically

2017-12-11 Thread Alastair Houghton

On 11 Dec 2017, at 13:53, Eric Matecki  wrote:
> 
> Thanks Jonathan,
> 
> I got a lot further now.
> So it is NSTableCellView, not NSTableViewCell as stated in the doc !

FWIW, NSTableViewCell is the old way to do it, before view-based tables were 
the norm, which probably explains your confusion here as the documentation most 
likely still covers both techniques.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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: Creating NSTableView programmatically

2017-12-11 Thread Eric Matecki


Thanks Jonathan,

I got a lot further now.
So it is NSTableCellView, not NSTableViewCell as stated in the doc !
I could have searched a long time before finding this out

I made my own text field class according to this (in NSTableCellView's doc) :
"""
The objectValue is used when setting the value of the view cell by the tableView:objectValueForTableColumn:row: method in the 
NSTableViewDataSource. If you use your own custom view cells that are not based on NSTableCellView you should implement this 
property in order to be able to receive changes to cell values.

"""
I added an "objectValue" property, with custom setter and getter, and updated 
the textfield's string in the setter.
Now I can see all the names :)

I'm on the saddle again for the rest of my journey...

Eric M.

On 11/12/2017 12:46, Jonathan Mitchell wrote:

For NSTableCellView see
https://developer.apple.com/documentation/appkit/nstablecellview

objectValue is a property on NSTableCellView not on NStableView.

The NSTableViewDelegate method
- (NSView *)tableView:(NSTableView *)tableView 
viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row
provides the required NSTableView instances on demand.

You also need to bind the NSTableView's content object to the 
NSArrayController’s arrangedObjects.

The nib makes all this easier  though its still fiddly.
I would get it working in a nib first and then work backwards from there.



On 11 Dec 2017, at 10:59, Eric Matecki  wrote:


Hello,

I'm trying to implement in Objective-C on macOS *programmatically* the "Real World 
Example" at the bottom of this page :
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html

I want to do it programmatically instead of using IB to really understand what 
happens.

Just creating the "Attacker" NSTableView causes me already a lot of trouble.
My code is at the bottom of this message.

I can't just bind "value" of the attacker tableview to the array controller's 
"arrangedObjects.name",
I get a "this class is not key value coding-compliant for the key value" 
exception.

So I create a column (I think this is mandatory anyway...).
In my delegates tableView:viewForTableColumn:row: I create a text field 
(NSTextView).
(I create a textfield for now, will probably be a NSButton in the final 
version).

I now see a table with four rows (the number of entries in my array), each with 
a text field I can edit.
But they start empty and don't change my array of combattants.

How do I bind this text field to the right "thing" ?

According to the last paragraph of this page:
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
I have to :
"""
When you make the connection to the table view’s Content binding, the 
objectValue property of the NSTableViewCell used as the cell for the table 
column is configured such that for each item in the model array, the table 
updates the objectValue property to the current row’s Person object.
"""
But NSTableViewCell doesn't seem to exists (a search on Apple's dev doc gives 
27 results... all about *UI*TableViewCell)

So I need to bind "value" from the text field to "objectValue.name" from... 
something...
Whatever I try I get either an exception for not KV compliance, or it doesn't 
seem to do anything.

Please shed some light on this...
Thanks.

CODE:

#include "Cocoa/Cocoa.h"

//===
 cCombattant

@interface  cCombattant : NSObject

@property (copy) NSString*  weapon1;
@property (copy) NSString*  weapon2;
@property (copy) NSString*  weapon3;
@property (copy,readwrite) NSString*  name;
@propertyNSString**  selectedWeapon;

- (cCombattant*)initWithName: (NSString*)  iName;

//DEBUG
- (void)addObserver: (NSObject *)observer
forKeyPath: (NSString *)keyPath
   options: (NSKeyValueObservingOptions)options
   context: (void *)context;

//DEBUG
- (void)removeObserver: (NSObject *)observer
   forKeyPath: (NSString *)keyPath;
@end


@implementation  cCombattant

- (cCombattant*)initWithName: (NSString*)  iName
{
   self = [super  init];

   [self  setWeapon1: @"Dagger"];
   [self  setWeapon2: @"Sword"];
   [self  setWeapon3: @"Pike"];
   [self  setSelectedWeapon: &_weapon1];
   [self  setName: iName];

   return  self;
}

//DEBUG
- (void)addObserver: (NSObject *)observer
forKeyPath: (NSString *)keyPath
   options: (NSKeyValueObservingOptions)options
   context: (void *)context
{
   printf( "[%p addObserver: %p forKeyPath: %s options: XXX context: %p]\n", 
self, observer, [keyPath UTF8String], /*options,*/ context );
   int bkpt=bkpt;
   [super  addObserver: observer  forKeyPath: keyPath  options: options  
context: context];
}

//DEBUG
- (void)removeObserver: (NSObject *)observer
   forKeyPa

Re: Creating NSTableView programmatically

2017-12-11 Thread Jonathan Mitchell

For NSTableCellView see
https://developer.apple.com/documentation/appkit/nstablecellview

objectValue is a property on NSTableCellView not on NStableView.

The NSTableViewDelegate method 
- (NSView *)tableView:(NSTableView *)tableView 
viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row
provides the required NSTableView instances on demand.

You also need to bind the NSTableView's content object to the 
NSArrayController’s arrangedObjects.

The nib makes all this easier  though its still fiddly.
I would get it working in a nib first and then work backwards from there.


> On 11 Dec 2017, at 10:59, Eric Matecki  wrote:
> 
> 
> Hello,
> 
> I'm trying to implement in Objective-C on macOS *programmatically* the "Real 
> World Example" at the bottom of this page :
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html
> 
> I want to do it programmatically instead of using IB to really understand 
> what happens.
> 
> Just creating the "Attacker" NSTableView causes me already a lot of trouble.
> My code is at the bottom of this message.
> 
> I can't just bind "value" of the attacker tableview to the array controller's 
> "arrangedObjects.name",
> I get a "this class is not key value coding-compliant for the key value" 
> exception.
> 
> So I create a column (I think this is mandatory anyway...).
> In my delegates tableView:viewForTableColumn:row: I create a text field 
> (NSTextView).
> (I create a textfield for now, will probably be a NSButton in the final 
> version).
> 
> I now see a table with four rows (the number of entries in my array), each 
> with a text field I can edit.
> But they start empty and don't change my array of combattants.
> 
> How do I bind this text field to the right "thing" ?
> 
> According to the last paragraph of this page:
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
> I have to :
> """
> When you make the connection to the table view’s Content binding, the 
> objectValue property of the NSTableViewCell used as the cell for the table 
> column is configured such that for each item in the model array, the table 
> updates the objectValue property to the current row’s Person object.
> """
> But NSTableViewCell doesn't seem to exists (a search on Apple's dev doc gives 
> 27 results... all about *UI*TableViewCell)
> 
> So I need to bind "value" from the text field to "objectValue.name" from... 
> something...
> Whatever I try I get either an exception for not KV compliance, or it doesn't 
> seem to do anything.
> 
> Please shed some light on this...
> Thanks.
> 
> CODE:
> 
> #include "Cocoa/Cocoa.h"
> 
> //===
>  cCombattant
> 
> @interface  cCombattant : NSObject
> 
> @property (copy) NSString*  weapon1;
> @property (copy) NSString*  weapon2;
> @property (copy) NSString*  weapon3;
> @property (copy,readwrite) NSString*  name;
> @propertyNSString**  selectedWeapon;
> 
> - (cCombattant*)initWithName: (NSString*)  iName;
> 
> //DEBUG
> - (void)addObserver: (NSObject *)observer
> forKeyPath: (NSString *)keyPath
>options: (NSKeyValueObservingOptions)options
>context: (void *)context;
> 
> //DEBUG
> - (void)removeObserver: (NSObject *)observer
>forKeyPath: (NSString *)keyPath;
> @end
> 
> 
> @implementation  cCombattant
> 
> - (cCombattant*)initWithName: (NSString*)  iName
> {
>self = [super  init];
> 
>[self  setWeapon1: @"Dagger"];
>[self  setWeapon2: @"Sword"];
>[self  setWeapon3: @"Pike"];
>[self  setSelectedWeapon: &_weapon1];
>[self  setName: iName];
> 
>return  self;
> }
> 
> //DEBUG
> - (void)addObserver: (NSObject *)observer
> forKeyPath: (NSString *)keyPath
>options: (NSKeyValueObservingOptions)options
>context: (void *)context
> {
>printf( "[%p addObserver: %p forKeyPath: %s options: XXX context: %p]\n", 
> self, observer, [keyPath UTF8String], /*options,*/ context );
>int bkpt=bkpt;
>[super  addObserver: observer  forKeyPath: keyPath  options: options  
> context: context];
> }
> 
> //DEBUG
> - (void)removeObserver: (NSObject *)observer
>forKeyPath: (NSString *)keyPath
> {
>printf( "[%p removeObserver: %p forKeyPath: %s]\n", self, observer, 
> [keyPath UTF8String] );
>int bkpt=bkpt;
>[super  removeObserver: observer  forKeyPath: keyPath];
> }
> 
> @end
> 
> //===
>  cDelegate
> 
> @interface  cDelegate : NSObject < NSTableViewDelegate >
> 
> - (cDelegate*)init;
> 
> @end
> 
> 
> @implementation  cDelegate
> 
> 
> - (cDelegate*)init
> {
>self = [super  init];
>return  self;
> }
> 
> - (NSView *)tableView:(NSTableView *)tableV

Creating NSTableView programmatically

2017-12-11 Thread Eric Matecki



Hello,

I'm trying to implement in Objective-C on macOS *programmatically* the "Real World 
Example" at the bottom of this page :
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html

I want to do it programmatically instead of using IB to really understand what 
happens.

Just creating the "Attacker" NSTableView causes me already a lot of trouble.
My code is at the bottom of this message.

I can't just bind "value" of the attacker tableview to the array controller's 
"arrangedObjects.name",
I get a "this class is not key value coding-compliant for the key value" 
exception.

So I create a column (I think this is mandatory anyway...).
In my delegates tableView:viewForTableColumn:row: I create a text field 
(NSTextView).
(I create a textfield for now, will probably be a NSButton in the final 
version).

I now see a table with four rows (the number of entries in my array), each with 
a text field I can edit.
But they start empty and don't change my array of combattants.

How do I bind this text field to the right "thing" ?

According to the last paragraph of this page:
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
I have to :
"""
When you make the connection to the table view’s Content binding, the objectValue property of the NSTableViewCell used as the cell 
for the table column is configured such that for each item in the model array, the table updates the objectValue property to the 
current row’s Person object.

"""
But NSTableViewCell doesn't seem to exists (a search on Apple's dev doc gives 
27 results... all about *UI*TableViewCell)

So I need to bind "value" from the text field to "objectValue.name" from... 
something...
Whatever I try I get either an exception for not KV compliance, or it doesn't 
seem to do anything.

Please shed some light on this...
Thanks.

CODE:

#include "Cocoa/Cocoa.h"

//===
 cCombattant

@interface  cCombattant : NSObject

@property (copy) NSString*  weapon1;
@property (copy) NSString*  weapon2;
@property (copy) NSString*  weapon3;
@property (copy,readwrite) NSString*  name;
@propertyNSString**  selectedWeapon;

- (cCombattant*)initWithName: (NSString*)  iName;

//DEBUG
- (void)addObserver: (NSObject *)observer
 forKeyPath: (NSString *)keyPath
options: (NSKeyValueObservingOptions)options
context: (void *)context;

//DEBUG
- (void)removeObserver: (NSObject *)observer
forKeyPath: (NSString *)keyPath;
@end


@implementation  cCombattant

- (cCombattant*)initWithName: (NSString*)  iName
{
self = [super  init];

[self  setWeapon1: @"Dagger"];
[self  setWeapon2: @"Sword"];
[self  setWeapon3: @"Pike"];
[self  setSelectedWeapon: &_weapon1];
[self  setName: iName];

return  self;
}

//DEBUG
- (void)addObserver: (NSObject *)observer
 forKeyPath: (NSString *)keyPath
options: (NSKeyValueObservingOptions)options
context: (void *)context
{
printf( "[%p addObserver: %p forKeyPath: %s options: XXX context: %p]\n", self, observer, [keyPath UTF8String], /*options,*/ 
context );

int bkpt=bkpt;
[super  addObserver: observer  forKeyPath: keyPath  options: options  
context: context];
}

//DEBUG
- (void)removeObserver: (NSObject *)observer
forKeyPath: (NSString *)keyPath
{
printf( "[%p removeObserver: %p forKeyPath: %s]\n", self, observer, 
[keyPath UTF8String] );
int bkpt=bkpt;
[super  removeObserver: observer  forKeyPath: keyPath];
}

@end

//===
 cDelegate

@interface  cDelegate : NSObject < NSTableViewDelegate >

- (cDelegate*)init;

@end


@implementation  cDelegate


- (cDelegate*)init
{
self = [super  init];
return  self;
}

- (NSView *)tableView:(NSTableView *)tableView
   viewForTableColumn:(NSTableColumn *)tableColumn
  row:(NSInteger)row
{
NSTextView*  view = [[NSTextView  alloc]  init];
[view  setRichText: NO];
[view  setFieldEditor: YES];
[view  bind: @"value"  toObject: tableView  withKeyPath: 
@"objectValue.name"  options: 0];
return  view;
}

@end

//===
 JustDoIt2()

void
JustDoIt2()
{
@try{
NSArray*  combattants =
[[NSArray  alloc]  initWithObjects:
[[cCombattant  alloc]  initWithName: @"Atilla"],
[[cCombattant  alloc]  initWithName: @"Vlad"],
[[cCombattant  alloc]  initWithName: @"Doris"],
[[cCombattant  alloc]  initWithName: @"Cthulhu"],
nil
 ];
printf("combattants = %p\n", combattants);

NSArrayController*

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Re: Creating NSTableView programmatically

Creating NSTableView programmatically

24 matches

Site Navigation

Mail list logo

Footer information