Re: Beginner Question About CustomView, -drawRect: and Plotting Data.
Re: Beginner Question About CustomView, -drawRect: and Plotting Data.
- Subject: Re: Beginner Question About CustomView, -drawRect: and Plotting Data.
- From: Scott Ellsworth <email@hidden>
- Date: Wed, 28 Jun 2006 16:02:22 -0700
On Jun 27, 2006, at 3:40 PM, Daniel J Farrell wrote:
This is getting a bit too complicated for me to understand now!
However, I've managed (finally after several hours) to get
something to work from the first suggestion.
Cocoa is designed around Model-View-Controller. Your model contains
the data, your view knows how to draw _any_ data, and your controller
keeps the two in sync. For example, if the data changes, your
controller tells the view to update, and possibly _what_ to update.
Similarly, if the user clicks a button in the view, or does something
else interesting, then the controller tells the model to change.
In your case, the model is changed by calculation. It is the job of
your controller to tell the view that something is new.
Take a look at <http://developer.apple.com/documentation/Cocoa/
Conceptual/ObjCTutorial/chapter02/chapter_2_section_3.html> for some
examples.
Have a look here:
http://www.boyfarrell.com/xcode/PlotView.dmg
I was unable to see anything in this dmg.
Current I have quite a traditional programme style where I
initialise all my objects an run code from the main.m file. I'm not
to sure how to integrate this method of working with the new code
that plots the data? All the number crunching happens inside my
Model class do I just have to paste all my current main.m code into
the -init method of the model so that if runs when it is called? Or
is there a more elegant solution?
The number crunching happens in your model class. Something has to
ask that to happen.
In a GUI app, you would probably put a button in your window that
says 'calculate this', and the action method for that button would
then call model methods to do the work.
During those model methods that do the work, you would probably have
occasional calls to tell the controller that something has changed,
at times when it has. The controller would then tell the view that
it is time to update.
For example, if the model has a 'userName' string and a connection to
the controller, and the controler has connections to the view and
model, it might look like this:
Model:
- (void)setUserName:(NSString *)inUserName{
[inUserName retain];
[userName release];
userName = inUserName;
[controller userNameChanged];
}
Controller:
- (void)userNameChanged{
[viewTextField setText:[model userName]];
// Note: the next line is only needed if you are doing a custom view.
// [view setNeedsDisplay:YES];
}
Sure, you _could_ have the model talk right to the view, but then
they are too closely coupled. It is easier, usually, to split them
this way. The view knows it has a text field, while the model knows
that the text is a user name. Only the controller knows that the
text field contains the user name.
An aside: The 'Cocoa Bindings' you hear talked about are a set of
Apple-written controller objects that handle certain common cases.
By creating an object controller that is hooked up to the Model, you
can set the NSTextField to get its value from the userName entry. No
code is needed to propagate a changed user name, and your set method
does not need to have [controller userNameChanged];
Aside done.
Hope you can see what I'm getting at? I'm just having to completely
change the way I've been working for the last year, it seems a bit
alien not doing everything from your main.m, instead you just have
one line in there:
return NSApplicationMain(argc, (const char **) argv);
The awakeFromNib method is a better spot, as then all connections in
IB have been completed. I usually, though, would hang this off a
button's action procedure.
The recent Cocoa-heads lake forest NavComCocoa project uses a timer
to change underlying model data. Take a look at
cocoaheads.sourceforge.net and go to the svn repository. The code is
not perfect, but it does at least give some idea of how timer driven
changes might be done.
SCott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden