On 8/30/11 8:59 PM, Jens Alfke wrote:
On Aug 30, 2011, at 8:43 PM, Julie Porter wrote:
NSLog(@"have %lu events.",[[MyDocument CISEvents] count]);
I get the error:
'MyDocument' may not respond to '+CISEvents'
This is the distinction between a class and an object. A class is a
kind of template that defines what data objects contain. It doesn’t
make any sense to use [MyDocument CISEvents]; it’s like asking “how
many spots does the word Leopard have?”. Properties apply to
individual objects, not to classes. This is pretty fundamental, and a
lot of other things in Cocoa programming (as with Java or many other
languages) won’t make sense until you’ve got it down.
I think the other thing you’re having trouble with is how to have the
different objects (not classes) in your app refer to each other. A
pretty common way to do this is for the controller object (the
document in your case) to initialize the view right after it loads by
telling it where the model object is. In your case I’m assuming the
array of events is the data model.
I have the idea that a class, MyDocument is instantiated with an array
myEvents, each time a file is opened.
A separate class MyView is opened by MyDocument by some sort of magic in
the controller glue.
I can see how the MyView class has no understanding of the myEvents
object as there is no clear connection to the MyDocument class other
than the controller magic.
What I do not get, is why an accessor such as an abstract getObject can
not get the Object from the open and instantiated MyDocument class. I
guess it need to have a link or line to the object in the MyDocument
class, since there is an instance of MyView spawned by the MyDocument,
it would seem that there should be a link between the two, but where is
this link hidden? Or do I need to make it programmatically?
So one solution is to give your view class a settable property that’s
also an array of events, and have the document set that property on
the view after the window loads. Typically you’d give the document
class an IBOutlet pointing to the view, and wire that up in IB. Then
as soon as the nib loads, the document knows the view and can
initialize it.
This is even more confusing, What does IB have to do with my database
and communication between functions? I thought this was for things like
buttons and cells so that when one presses a button the value in a cell
is passed to the function.
I think I need to look up the definition of property. That may be what
I am not understanding. That I abstract property and key as the same
thing.
Will attempt to read more on IB Outlet abstractions, but am not sure
what an IBOutlet is in relation to my array of events. Which I am
pretty sure is the Data Model. (apart from the arrays of dicts I could
draw the keys and values using the list view CoreData tools.)
In postscript I have a dictionary open on the stack that contains my
array of dictionaries. If I open another dictionary on the stack I can
read in my array, but any new define instances are declared in local to
the new dictionary. When I close that top level dictionary I can no
longer access any local changes.
I think cocoa is the other way around, Where the document which has the
array of dictionaries I want is not visible to the View because the view
is not open to the document.
I also keep seeing stuff relating to KVO. This relates to the really
nifty Departments and employees type list, that sort of seem to happen
with bindings. But that system will not let me have arrays of dicts
inside arrays of dicts unless I can program them through classes or what
ever abstraction I am failing to understand. Problem is I am not
writing mail or iTunes, that has already been done.
I think KVO is what, in the long term, I want. Connecting things in IB
seems even more like going down the wrong path. Again in postscript I
have keys and values. This is what is in my dictionary. One key might
be @"StartLine" another key abstracts as @"EndLine"
I have keys and values. I want to observe them between classes.
Nothing more, nothing less.
Saw the second part relating to OoP as they used to call it. I remember
liking smalltalk and Logo, but I was in high school at the time 35 years
ago. the world went to procedural programming. A lot of this really
feels like a waste of time. Makework for programmers. I thought the
point of such was to abstract things so that one can concentrate on the
not so common code.
There really should be a framework tutorial out there that works for
scrolling graphics the same way one can scroll text. A black box where
one only has to deal with the drawRect procedure that is file based.
-julie
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
