From: Jonathan P. <jp...@dc...> - 2005-06-17 08:49:51
|
On 16 Jun 2005, at 17:44, Dave Howell wrote: > On Jun 14, 2005, at 12:01 AM, Jonathan Paisley wrote: > >> For this to work, you'd need to do >> NSImage.alloc.initByReferencingFile(blahblah). >> >> However, I there's also NSImage.imageNamed(blahblah) which should >> work. >> > > Ah. Just when I thought I'd finally managed to really internalize > and keep separate classes and instantiations, Obj-C rises up and > bites me with the same thing. Hmm. > OK, so the NSImage.alloc.initByReferencingFile(blahblah) didn't > seem to work either, but NSImage.imageNamed(blahblah) worked > perfectly. :) :) > > Except that it doesn't automatically update. If I roll the dice, > and replace the data in the array, it only updates when I move > focus to another app or back. I'm pretty sure I know how to fix > that, but I thought to myself "oho! Wouldn't this be better if I > used Bindings instead of simulating a datasource?" Have you told the table that you've updated the data source? Call reloadData on the table view. To be honest, I think for this application you're better to use the standard datasource techniques rather than bindings. Bindings tend to be more useful when there's different ways to edit or view data (e.g., both directly in the table and also in a bunch of fields below the table). > Well, maybe, but now I can't get *that* to work. All the examples I > find are too complicated; they assume that I want to the user to be > able to edit and fiddle. This is display only, so I need to be able > to write into the array programmatically and have it update. I > think what's not working is that I can't convince the table view to > actually connect to the array. This reinforces my point above - they're all too complicated because it's most useful when you have that complexity. I suggest you go back to using a table datasource and try calling reloadData on the table view. > I'm mostly working off the Intro To Cocoa Bindings article on the > cocoadevcentral site, which creates a little email mailbox & > messages app. The final "code" for the project is this: > > @interface MyController : NSObject > { > NSMutableArray * _mailboxes; > } > > - (NSMutableArray *) mailboxes; > - (void) setMailboxes: (NSArray *)newMailboxes; > > @end > > > I can't quite figure out how that translates into RubyCocoa. (The > initial {} part is mystifying, dumb old Obj-C grumble grumble.) > Here's my best guess so far: Not dumb: the {} bit is just the declaration of instance variables. > > class MyController < OSX::NSObject > include OSX > > ib_outlet :mailboxes > > def initialize > @mailboxes = NSMutableArray.alloc.init > end > end > > There's no 'def setMailboxes' because I don't want mine to be > writable, so I haven't been trying to figure out the correct syntax > for that. Anything wrong so far? Bear in mind that preventing the array from being replaced is not the same as preventing its contents from being changed. The contents could be changed both by calling methods on the array (@mailboxes.addObject) and also by changing the properties of any of the contained objects. > I scrapped and rebuilt all the stuff in Interface Builder, and now > something appears to be connected that wasn't connected before. > Instead of just launching silently, now when I launch it aborts > with this error: > this class is not key value coding-compliant for the key diceRoll The current release of RubyCocoa (0.4.1) doesn't support bindings 'out of the box'. There's some extra code you need to get it to work. This has since been integrated into CVS, so the next release will have it. You can see what's required by looking at the FAQ: http:// rubycocoa.sourceforge.net/w.en/FAQ.html "I'm trying to use Cocoa Bindings but all I get is an error message saying that my class is not key value coding-compliant (kvc)". There's a DMG of a sample project linked at the end of the FAQ entry. |