Article:  |
Building a Scratch Pad with Cocoa | |
| Subject: | NSBezier subclass for ColoredPath | |
| Date: | 2001-12-08 23:48:12 | |
| From: | psheldon | |
|
Response to: small steps on my own to three color padview
|
||
|
Ran off to party and perhaps let go of too much code to the thread. Maybe someone can speed read it and see what I was trying to do. Not that they should finish my assumed homework for me, but could my own structs serve as an addanobject for an NSMutableArray and how do I birth a struct other than on a stack? There isn't a NEW, is there, in objective C? I think that a subclass could have an NSColor would inherit a constructor and not have the dot problem because I wouldn't be using a struct. Nor would I try to do something crazy like retain an address on a stack, though I don't particularly know why it is crazy, just suspect it so. I guess I would add an accessor method for the color of the ColoredPath. I heard someone at an Apple seminar say that objects were much better than structs. He didn't formally declare why but just seemed to assure from experience. Maybe some more talk than his would make me see the trades of using structs rather than a subclass. |
||
Showing messages 1 through 3 of 3.
-
NSBezier subclass creation set with no get accessor
2001-12-09 07:06:48 psheldon [Reply | View]
-
works but with warning (short code eg.)
2001-12-10 09:24:48 psheldon [Reply | View]
ColorBezier.m:20: warning: instance variable `theColor' accessed in class method
+ (ColorBezier*)initWithColor:(NSColor*)color {
self = [[super bezierPath] retain];
if (self) {
theColor = color;
}
return self;
}
-
got rid of warning with accessor and less self
2001-12-11 10:15:44 psheldon [Reply | View]
I really don't know the meaning of "self" in newtonscript and objective C and need some years of pain, probably, to teach me the intuition and, beyond, perhaps to formalize into words. I think it is the left argument in the square brackets at first, be it class or instance.
When I tried to make a new version that used a ColorWell, all my plans went haywire, as I doubted I had understood memory managment deep in my bones. I threw in retains and releases and perhaps too many retains knowing that when I quit, it would clean house, maybe. Still no change of color. I think the click in the color well ran the mousedown method and I got messages about not having a point for a line as soon as I tried to draw. I got rid of those error messages, without understanding them really, by insuring that I last clicked on a button I called "Well" by putting code assigning a new path in the action associated with that button in padView.
So, having gotten rid of an error message, I went on to see that my color didn't change because my ColorBezier subclass of NSBezierpath didn't change. So, perhaps I don't know how to think in assigning currentPath because of this pointer retain and release stuff not having sunk in.
Perhaps the button and colorwell actions may illustrate my confusion rather than all my code :
- (IBAction)ChooseWell:(id)sender
{
[pathCurrent release];
pathCurrent = [ColorBezier initWithColor: colorCurrent];
[pathCurrent retain];
[ColorPaths addObject: pathCurrent];
}
- (IBAction)colorWellAction:(id)sender
{
float *locRed,*locGreen,*locBlue,*locAlpha;
[colorCurrent release];
colorCurrent = [sender color];
[colorCurrent retain];
//[colorCurrent getRed:locRed green:locGreen blue:locBlue alpha:locAlpha];
[colorCurrent set];
//[colorCurrent getRed:locRed green:locGreen blue:locBlue alpha:locAlpha];
}
I am not clear with the "fuzzy typing" whether I could make a subclass of ColorPath be ColorPaths because of my narrow focus on the methods of NSBezierclass. Apple didn't do this in sketch, so I think it would be too much of a stretch for me to try to do.