Re: IB is listing non-outlets as outlets
Re: IB is listing non-outlets as outlets
- Subject: Re: IB is listing non-outlets as outlets
- From: Kevin Viggers <email@hidden>
- Date: Wed, 23 Mar 2005 13:50:26 -0700
Hi Ricky,
There is some stuff in the IBFAQs (quoted for convenience below), but
this essentially repeats what Joar has already mentioned. If you really
want these ivars to disappear though, you could hide them from IB by
providing a type alias for id. Something like this.
typedef HiddenId id;
@interface MyControl : NSControl
{
@private
HiddenId observedObjectForFoo;
NSString* observedKeyPathForFoo;
}
@end
Not the ideal solution, letting your tools get the best of you, but one
at least.
Kevin
==================================================
• What are IBOutlet and IBAction doing in my code?
The short answer to this question is "not much". To really understand
why they're added to your code, you must understand how IB parses your
code. When you choose Classes:Read Files, IB tries to find the outlets
and actions you've declared in your header. Long ago, we relied on
these signatures:
for Outlets: id someOutlet;
for Actions: -(void)myAction:(id)sender
However, some people prefer stronger typing of their outlets, so they
would try:
for Outlets: NSTextField* someOutlet;
for Actions: -(void)myAction:(MyApplication*)sender;
Nicely typed for sure, but IB couldn't tell the difference between
these signatures and other non-outlet/non-action declarations, so it
ignored them. To solve this dilemma, the no-op keywords IBOutlet and
IBAction were introduced. Although the very first set of signatures
still works, IB will also parse methods and fields containing these
keywords as shown below:
for Outlets: IBOutlet NSTextField* someOutlet;
for Actions: -(IBAction)myAction:(MyApplication*)sender;
On 18-Mar-05, at 5:31 PM, j o a r wrote:
IB rather recently got support for IBOutlet and typed outlets. Prior
to that all outlets were of the type "id". Supporting "id" after the
addition of typed outlets is probably done for backwards
compatibility. You can find some info on this in the IB release notes.
j o a r
On 2005-03-19, at 00.09, Ricky Sharp wrote:
This is probably a bug in IB, but thought I'd post here first.
For my custom palette items (mostly subclasses of NSControl), I offer
custom bindings. For a particular binding, the control subclass has
a pair of private ivars. For example:
@interface MyControl : NSControl
{
@private
id observedObjectForFoo;
NSString* observedKeyPathForFoo;
}
In IB, when I control drag from such a control (e.g. to connect up
delegates, next key view, etc.), I'm seeing a list of these private
id ivars as if they were declared as being outlets. In the example
above, 'observedObjectForFoo' would show up in the list of outlets I
could connect to.
It's not a huge deal as I'm the only one that will ever use these
palette items and I know not to connect such things. Still, it does
clutter the list of outlets especially for those controls that offer
several custom bindings.
Anyone know why IB is doing this?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden