RE: Programmatically create view and handle events
RE: Programmatically create view and handle events
- Subject: RE: Programmatically create view and handle events
- From: Shawn Bakhtiar <email@hidden>
- Date: Thu, 27 Jan 2011 12:17:28 -0500
- Importance: Normal
If you come from Microsoft or like me GTK (which are somewhat alike), your going to have a hard time (as I did) adjusting to the use of the NIB (which very much feels like - does not function like - the old MFC RES files) with two fundamental differences.
1) You can use custom classes in the NIB that inherit the base object. EI you can create and implement a class that inherits NSView, lets call it MYNSView, and use it as an NSView in the NIB (Open the Inspector and click the Identity tab, in Interface Builder). Once set, Interface Builder shows the properties and
2) signals you have added to your object, which can be connected to any other element in the interface.
This is an awesome feature! You define your classes in Xcode, than simply load and connect them in the NIB.
To do this programmatically you would simply do IE (self is a custom class that inherits from NSView):
NSTextField * jobNumber = [[NSTextField alloc] initWithFrame:NSMakeRect(70, 40, 100, 27)];
[jobNumber setTarget:self];
[jobNumber setAction:@selector(jobNumberActivate:)];
[self addSubview:jobNumber];
This sets the target (the object which will receive the signal) to self (the creator of the NSTextField) and the action (what you and I may refer to as the callback function) to jobNumberActivate which is than defined as:
- (IBAction)jobNumberActivate:(id)sender;
{
// TODO: YOUR CODE HERE
}
Like I said, I find using the NIB awkward not for its lack of ability but more a lifetime of creating and connecting objects in the program itself. So I tend to think in those lines. But like I said, the interface builder is a very sweet tool, and I would be negligent not to recommend the use of it, unless there is a specific reason for it.
I would spend some time reading:
NSview - you already know what this is
http://developer.apple.com/library/mac/#documentation/cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/occ/cl/NSView
NSResponder - Which handles most of the key and mouse events
http://developer.apple.com/library/mac/#documentation/cocoa/Reference/ApplicationKit/Classes/NSControl_Class/Reference/Reference.html#//apple_ref/occ/cl/NSControl
NSControl - Which is what your question is about (Which inherits NSView and NSResponder, and is the base for most of the controls used in Cocoa ie NSTextField)
http://developer.apple.com/library/mac/#documentation/cocoa/Reference/ApplicationKit/Classes/NSControl_Class/Reference/Reference.html#//apple_ref/occ/cl/NSControl
Read about Messaging here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html#//apple_ref/doc/uid/TP40008048-CH104
> Date: Thu, 27 Jan 2011 10:45:52 +0100
> From: email@hidden
> To: email@hidden
> CC: email@hidden
> Subject: Re: Programmatically create view and handle events
>
> 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 <email@hidden>
>
> > 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 (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
_______________________________________________
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