Uli, Thanks for your patient!
I know that this snippet seems without any sense; my point is only on "handling events". I was trying to handle a drawRect: on a view created dynamically. Let me explain: I come from .NET, where there is a completely different approach, especially about creating controls dynamically and catching their own events. I was supposing that after I have created an NSView dynamically I could handle its drawRect... However, I think I will follow you suggestion and I start using IB. Thank you again. L 2011/1/27 Uli Kusterer <witness.of.teacht...@gmx.net> > On Jan 26, 2011, at 5:29 PM, Luca Tarozzi wrote: > > I am new to cocoa and objective C. > > Hi and welcome to Cocoa! I'm sure you'll have fun! The learning curve at > the start is a bit steep, but don't worry, it'll get easier after a while > :-) > > > I am looking for a way to handle events for a NSView created > > programmatically (without IB). > > Sure. There's lots of good documentation on views on Apple's developer > site <http://developer.apple.com>. The thing to keep in mind when creating > views programmatically is that they're just normal objects, so you just > create them, use addView to insert them in the hierarchy on the screen (e.g. > into a window's contentView). > > But honestly, this is an odd thing to want to do as your first Cocoa > project. What are you trying to create where you need to create a view in > code? Usually just dropping views in a NIB and using an NSViewController to > load that, then inserting the view(s) loaded like that into whatever parent > view is a more common approach. You can even create several instances of the > same view controller class, thus giving you several copies of the object in > one NIB. > > > Is it possible starting from the following code? > > > > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { > > > > // Insert code here to initialize your application > > > > // [[NSColor yellowColor] set]; > > Where will that color go? You're not in drawRect:, so you probably don't > have a drawing context to draw into. > > > NSView *superView = [window contentView]; > > > > // [NSBezierPath fillRect:[superView bounds]]; > > > > NSRect frame = NSMakeRect(50, 50, 200, 100); > > > > NSView *myView = [[NSView alloc] initWithFrame:frame]; > > > > [superView addSubview:myView]; > > Okay, creating a view here and inserting it in the window's superview, > perfectly fine code that does what you said you wanted to do. But why create > a plain NSView? Plain NSViews are usually either used as a base class for > your own custom views, or as containers to group together other views > invisibly (e.g. so you can easily hide several views as once). > > > [[NSColor greenColor] set]; > > > > [NSBezierPath fillRect:[myView bounds]]; > > Again, unmotivated drawing code hanging in mid-air. Is this supposed to be > shown in the view? Views aren't just canvases to draw in. Look at the view > programming guide Apple has to see how to create your own NSView subclasses > and draw custom stuff in them. If you just want to show a little > decorational image, look at NSImage and NSImageView. If it's anything more > complex (like a graph, or something that has clickable parts), NSView > subclass is probably the place to go. > > > [myView setTarget:self] > > 1) Missing semicolon > > 2) A target without an action is kind of pointless > > 3) NSView doesn't have a setTarget: method, nor a setAction: method. If > you implement your own NSView subclass, you can implement your own > target/action methods (just a SEL and an id property, and then use > -performSelector:withObject: inherited from NSObject). Otherwise, create > another class that has such a property, e.g. an NSButton, NSTextField or > other NSControl subclass are generally good candidates. > > > // [myView setNeedsDisplay:YES]; > > > > [myView release]; > > Thanks for putting the "release" in there. Always good to see you've taken > the time to read the memory management rules :-) Many people don't bother > memorizing the rules on Apple's web site ( > http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html) > and then muddle around and keep crashing because they free objects owned by > others etc. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.masters-of-the-void.com > > > > _______________________________________________ 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
