Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

[<bb...@ma...>]

On Saturday, November 16, 2002, at 03:52 PM, Just van Rossum wrote:
> Ok. I've renamed the NibInfo.printOverview() method to 
> NibInfo.printTemplate().
> It will print a Python template with stubs for actions and comments 
> for outlets.
> NibLoader.py is converging back to classnib.py ;-)

Subsuming the features of classnib.py, more likely.

> The thing that I don't understand is why they are class attributes: 
> I'd expect
> (but then again, I don't grok them yet) they'd be specific to an 
> instance, and
> therefore be instance attributes. How does it work?

They are instance variables on the ObjC side.  If I declare an outlet 
named 'randomOutlet' and an action named 'randomAction:' in a class 
called ExampleObject and then generate the source, the following 
declaration results...

@interface ExampleObject : NSObject
{
     IBOutlet id randomOutlet;
}
- (IBAction)randomAction:(id)sender;
@end

... where IBOutlet and IBAction are declared as follows...

#define IBOutlet
#define IBAction void

IBOutlet and IBAction both exist for the sole purpose of providing for 
easy parsing of actions and outlets in IB itself.  There is nothing 
special about either declaration in terms of the ObjC language or at 
runtime.

When a NIB is loaded, it goes through a process of making the 
connections defined in the NIB (there are more than just outlets and 
actions, but we will ignore those for now).   For actions, this is 
simply a matter of setting the target and action for each object that 
has a target/action.   Literally, calling setTarget: and setAction: on 
each button, table, etc.. that has such set.   Target/action 
connections to FirstResponder simply setTarget: to nil (indicating that 
the action should be handled by the first responder in the chain that 
implements the action).

If the NIB has an object with a target/action connection where both the 
target and the action are set, but the runtime indicates that the 
target does not implement the action, the above error message is 
printed.

For Outlets, the connection process simply sets the instance variable 
directly, if possible.   However, before doing so, it checks to see if 
the object contains the method setOutletName: and, if so, calls that 
method instead, passing the object that it will be connected to as the 
first argument (i.e. if ExampleObject implemented -setRandomObject: it 
would be called instead of just making a direct connection).

Hope that helps (and looking at NibLoader, I'm not at all certain how 
the outlets are working... but they do seem to be working fine!)...

b.bum