Re: Subclassing a button
Re: Subclassing a button
- Subject: Re: Subclassing a button
- From: Charles Bennett <email@hidden>
- Date: Mon, 12 Aug 2002 09:51:23 -0400
Graeme Nattress wrote:
I'm really new to Cocoa, so some help would be appreciated.
I'm writing a little application to hack renderman rib files. The main
code is in TCL and I've worked out how to get a Cocoa interface to run
my shell scripts. I'm working on an interface in Cocoa so as to help me
learn.
There are many options in the software and I want to present each on a
tabbed window. There are many points at which a user will want to select
a rib file,
So the user is doing the selection.. You should be using
NSOpenPanel to get the selection.
and I've written a little app in Cocoa that allows a user to
select a file when they press a button, putting the path into a text
box. I'd like to make a way that I can duplicate this functionality
throughout my app. What I've tried is to subclass NSButton and add in my
own code, and I've overroad the definition of stringValue so that I can
set the target of my button in IB to a text field, and when I press the
button, it puts a value in the right box, which I take from the
buttons's instance variable that I set up. However, I'm not sure how to
add in my code to let the user select a file from disc.
It is very, and I mean VERY, rare to subclass any of the common controls like NSButton.
I know that a lot of dev enviroments work that way where, if you want to add action to a button,
you start by subclassing button... Need a dialog box.. start by subclassing dialog..
Very 20th century ;-)
Generally, at the level you are working at you won't need to subclass much other than NSObject.
You may need or want a couple of them, but I'd bet that one will do for now..
What you need to get used to is what we call Model/View/Controller or MVC
A REALLY short, incomplete, and cheesy MVC explaination:
The MVC way is to create an object that is the nexus of control actions and write the code to do what you want there.
This object (the controller) sits between the model (the current state of process you are modeling) and the view (the
visual indication of the state of the model) modifications to the model (requested in the view by button presses etc.
or by other events) are sent to the controller object where it takes what ever actions are needed to change the model
and updates the view to reflect the new state of the model.
So, in the MVC way, would would have created an object to be the target of the the button.
Pressing the button would have brought up a NSOpenPanel to let the user pick the file.
Selecting a file would return the file name that the user selected to the controller.
The controller object would then update the textfield with the result and take any other actions you need.
No subclassing of anything other than NSObject to hold your controller code is needed.
That NSObject would have outlets to the text field(s) and anything else on the
display that you need to update. It would have target methods to deal with
button presses etc.. It may need to implement and be a delegate for the textfields
and/or window to handle things like the window close. It might even need to be the entire
applications delegate so you have a place to handle application initialization etc..
I'm still trying to get my head around this new fangled cocoa object
oriented approach after many years of more procedural programming. Any
help appreciated.
Graeme
Start here and get the idea of MVC firmly in hand..
http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/ObjC.pdf
Also I'd suggest the Garfinkle/Mahony book on Cocoa and the Hillegras book. Both are pretty good.
--
UPS Management software for OS X
http://www.powerguardian.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.