> On Sep 12, 2015, at 08:59, [email protected] wrote: > > You would implement the NSTableView data source and delegate methods in a > class. In a simple case in the app delegate to try them out and get used to > them.
That's how my project started out, using a data source and delegate (in the same file), and calling table.reloadData() every time there was a change. My problem was that updates to my model happened asynchronously, inside a third-party framework, and I had no way of knowing when the updates were complete. Reloading would usually happen well before the model had updated, so i'd have to manually update (using a button in the app) a few times before the new data would appear. With bindings, this isn't a problem anymore, or won't be once I implement them in my app. My question was rather obvious in retrospect, but I had my project in mind when I asked it and didn't think about it. :) I should have said: if you need to display an array or dictionary in a table, when that data source could be updated at a random time or asynchronously, how might you do it without bindings? Again, just curious; now I've gotten bindings working, I want to use them, at least until I fully grasp them and am comfortable using them whenever the situation calls for them. I won't be switching away from them for a while. > > Sent from my iPhone > >> On Sep 12, 2015, at 9:28 PM, Alex Hall <[email protected]> wrote: >> >> IT! WORKS! Thanks so much for your help. Now I'll advance this project, to >> test more aspects of this binding, and hopefully grasp things more >> completely with practical examples I make. >> >> Out of curiosity, you said you never use table view bindings anymore. If you >> had to display the contents of an array or dictionary in a table, what would >> you use instead? >>> On Sep 12, 2015, at 00:05, Quincey Morris >>> <[email protected]> wrote: >>> >>> On Sep 11, 2015, at 20:20 , Alex Hall <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> Okay, the error I'm seeing (about [ViewController count]) is the table >>>> asking for how big it should be. >>> >>> Actually, that’s not it, though you can be excused for thinking so. >>> >>> What’s wrong is that you tried to add way too many bindings, in particular >>> to the array controller. The only binding needed is the content binding. >>> The managedObjectContext binding must NOT be used, because this is not a >>> Core Data data model (but it probably makes no difference because it’s >>> referencing nil and so I expect the array controller just ignores it). The >>> selectionIndexes and sortDescriptors CANNOT be used in the project as it >>> stands, because your view controller does not have any corresponding >>> properties to bind to. The ‘count’ here is asking for the models’ opinion >>> of the number of selected rows, or the number of sort descriptors. It’s not >>> easy to tell which. In order to use these bindings, the view controller >>> would have to have properties with names that match the model keys. >>> Remember that the model key is just a string. It can’t cause any properties >>> or methods to exist — you have to do that part. >>> >>> After fixing that, your app crashes with a different error, which is a kind >>> of success because things got a lot further! >>> >>> The later crash was because you bound the wrong thing (that is, the wrong >>> “from” object) when trying to get hold of displayText. In the IB object >>> hierarchy, you bound the thing called “Text Cell”, which is actually a >>> prototype NSCell used for the column header. Normally you just treat is as >>> part of IB’s implementation details and don’t modify it directly. >>> >>> There’s a sub-hierarchy of 3 other things, called “Table Cell View” (which >>> is a NSTableCellView, and it’s the prototype of the top level view for each >>> cell), "Table View Cell” (which is your text field), and “Table View Cell” >>> (yes, the same name, which is the NSCell that the NSTextField machinery >>> uses and you similarly ignore in IB, in most cases). >>> >>> So after deleting the incorrect “Text Cell” binding, your project runs, >>> although the rows don’t show anything because the text field isn’t actually >>> (wasn’t ever) bound to anything. >>> >>> To complete this example — to get the text from Tweet.displayText to be >>> shown in the table — you have to hook up the the text field (the one called >>> “Table Cell View”, but not the NSCell of that name) via binding or whatever >>> so that it resolves its value through the Table Cell View’s objectValue. >>> That’s the “advanced” part, and I don’t remember exactly what to do because >>> I never use table view content bindings any more. If you carefully follow >>> through the example of table content bindings the table view programming >>> guide, you should be able to figure this out, but you’re on your own. I >>> don’t feel obliged to make your self-inflicted pain my self-inflicted pain. >>> :) >>> >>>> That makes way more sense--I was under the impression that the array >>>> controller was asking on the table's behalf, that's why I expected it to >>>> use countOfTweets(). >>> >>> As it turned out, the array controller wasn’t asking about the tweets at >>> all. But if it was, it would use “count" because it’s an *array* >>> controller, and the standard behavior that returns the count is “count”. >>> Note that the table view doesn’t even know the name of the relevant >>> property, because it’s hidden on the “other” side of the array controller, >>> not to mention buried inside a binding. It’s “count” all the way down the >>> line. >> >> >> -- >> Have a great day, >> Alex Hall >> [email protected] >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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/dangerwillrobinsondanger%40gmail.com >> >> This email sent to [email protected] -- Have a great day, Alex Hall [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
