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