Re: After Unarchive Object Exists, After First GUI Action, gone...
Re: After Unarchive Object Exists, After First GUI Action, gone...
- Subject: Re: After Unarchive Object Exists, After First GUI Action, gone...
- From: John Joyce <email@hidden>
- Date: Mon, 21 Apr 2008 07:42:26 -0500
On Apr 21, 2008, at 6:45 AM, email@hidden wrote:
Date: Mon, 21 Apr 2008 01:16:56 -0700
From: Andrew Farmer <email@hidden>
Subject: Re: After Unarchive Object Exists, After First GUI Action,
gone...
To: John Joyce <email@hidden>
Cc: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 20 Apr 08, at 18:55, John Joyce wrote:
Looks like I found a solution... anyone please let me know if my
solution stinks. (or any of the rest of this thing!)
In the method
- (void)windowControllerDidLoadNib:(NSWindowController *) aController
I added this:
[textView setString:[[stickitNotes objectAtIndex:0] noteBody]];
A few general notes:
1. You should never have to call setNeedsDisplay: on anything except
self (in NSView subclasses). A properly written view will do that on
its own when its contents change.
2. There's a lot of duplication in your code. You should probably
factor out some common code into a new method (updateCurrentNotes?
setNoteIndex?). Alternatively, you may want to take a look at Cocoa
Bindings - in particular, NSArrayController - which should be able to
do a lot of this work for you.
Thanks Andrew, yep, that's where I picked up setNeedsDisplay, so I
was just trying it to see if I was missing something.
As for the duplication, yeah, I am aware of it, but refactoring can
come in after functionality for this. I've worked with Ruby a lot so
I'm willing to write rough drafts and fix it later.
I agree and was thinking that Bindings would possibly be the way to
go for this. I actually just lifted large bits of the thing from the
Hillegass book's RaiseMan application, which is a terrible app that
introduces a lot of different elements of Cocoa at once.
the trickiest part of bindings seems to me to be the key paths.
Getting those right (and some of the settings in the inspector
palette in IB) is a bit mysterious. Do bindings rely mainly on
NSDictionary or do they work well with NSArray too? In this case, I'm
building a note app to replace stickies for a very specific workflow.
I just need it to be fast and stable with a small footprint. Things
could be refactored to use dictionaries for more meta data, and
probably will be, but NSArray seems to be the fastest lookup and is
already sequential.
But for now I'm just trying to wrap my head around enough of the
Cocoa basics.
In particular, after Ruby (not even Rails necessarily) I feel quite
comfortable with Objective C and Cocoa, but sometimes I feel like
methods I should have are not there, or I can't guess the name of
them. It's probably me thinking Ruby, but I often feel like I'm just
missing methods for NSArray...
_______________________________________________
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