help getting outlet to work

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Wizumwalt@gmail.com - 23 Jun 2007 03:54 GMT

Hi all,

I have an outlet in controllerA and I've added the outlet through the
NIB window also to controllerA. I then made a connection from
controllerA to controllerB. In the class inspector of this controller
I changed the type for the outlet to the name of the target controller
(controllerB) class.

[controllerB testMethod];

When I run my app, I keep getting this error ...

*** -[NSCFArray testMethod]: selector not recognized [self =
0x386aa0]

I don't know why NSCFArray shows up, nor do I understand why the
[self ...] is there. I've done many outlets to controllers here and
they all work expect for this area. I keep checking the NIB instances
and classes and redoing this outlet, but I can't get it to work.

Anyone have any ideas?

Reply to this Message

Gregory Weston - 23 Jun 2007 08:08 GMT

> Hi all,
>
[quoted text clipped - 17 lines]
>
> Anyone have any ideas?

You're not connecting the thing you think you are in the nib _or_ you
are but you're overwriting it with something else, possibly without even
explicitly setting things, before you get around to sending the
testMethod message.

The message you're getting essentially says you're sending testMethod to
an NSArray, not to a whatever-the-class-of-controllerB-is.

Can you be a little more explicit about what you've set up? The summary
you presented is kind of a tough read. What I think you're saying is:

You've got a class Foo and have made an instance in the nib called
controllerA.
You've got a class Bar and have made an instance in the nib called
controllerB.
Foo has an outlet named controllerB, with a type of Bar*.

Do you happen to have a method in Foo named setControllerB: (or
'set'-whatever-the-name-of-that-outlet-is:)?

Reply to this Message

Wizumwalt@gmail.com - 23 Jun 2007 17:34 GMT

> You're not connecting the thing you think you are in the nib _or_ you
> are but you're overwriting it with something else, possibly without even
> explicitly setting things, before you get around to sending the
> testMethod message.

I can't see that I'm overwriting anything at all. I even added a new
outlet, set it's type to id in the class inspector, and connected it
from controllerA to controllerB, then made the call [testOutlet
testMethod], and it did the very same thing. I got the same error.
And that's the only place it's used.

So I don't believe I'm overwriting anything. So that leaves the "I'm
not connecting to what I think it is" scenario. But in the NIB window,
the controller I'm connecting to really is what I think it is.
controllerB's files subclass from NSObject and it's instantiated as
controllerB in the NIB window.

> The message you're getting essentially says you're sending testMethod to
> an NSArray, not to a whatever-the-class-of-controllerB-is.

I can't see anywhere's why it would think I'm connecting to an
NSArray. I keep going all throughout class inspector and the NIB
window and see nothing that would make it think there's an NSArray
there. I did just try something else. On the outlet I just created in
controllerA I make a call like [testOutlet testMethod] and no matter
what I set the outlets type to in the class inspector, I get the same
error.

> Can you be a little more explicit about what you've set up? The summary
> you presented is kind of a tough read. What I think you're saying is:
[quoted text clipped - 4 lines]
> controllerB.
> Foo has an outlet named controllerB, with a type of Bar*.

Yes, that's exactly what I'm doing.

> Do you happen to have a method in Foo named setControllerB: (or
> 'set'-whatever-the-name-of-that-outlet-is:)?

No, none whatsoever.

Reply to this Message

Wizumwalt@gmail.com - 23 Jun 2007 18:31 GMT

As another note, I've been removing, recreating, reparsing,
reconnecting, cleaning, building, etc... and it's driving me crazy.

On the additional outlet that I created, I put the method call in
controllerA's awakeFromNib: method and it still returned the error, so
even though I only have one call in my entire app for

[testOutlet testMethod];

it still returns the error early on. I don't know what's going on.

Reply to this Message

Michael Ash - 23 Jun 2007 23:53 GMT

> As another note, I've been removing, recreating, reparsing,
> reconnecting, cleaning, building, etc... and it's driving me crazy.
[quoted text clipped - 6 lines]
>
> it still returns the error early on. I don't know what's going on.

Your ClassB (the class of testOutlet) init method is missing a return
statement.

Signature

Michael Ash
Rogue Amoeba Software

Reply to this Message

Wizumwalt@gmail.com - 24 Jun 2007 00:38 GMT

> Your ClassB (the class of testOutlet) init method is missing a return
> statement.

No, the init returns self. I put [testOutlet testMethod] inside my
awakeFromNib of controllerA which returns void. That's an outlet that
connects to controllerB. I put it there because afaik, the nib hasn't
been opened up yet when in the init. Otherwise, my app init's and runs
fine except for when it gets to these outlets.

For some reason, now it's like it doesn't know what the controller it
connects to means anymore.

Reply to this Message

Gregory Weston - 24 Jun 2007 13:57 GMT

> > You're not connecting the thing you think you are in the nib _or_ you
> > are but you're overwriting it with something else, possibly without even
[quoted text clipped - 18 lines]
> I can't see anywhere's why it would think I'm connecting to an
> NSArray.

It thinks it's an NSArray (or specifically an NSCFArray) because it's
looking up the runtime type information for the object at the address in
that pointer and seeing the magic value that says it's an NSCFArray.
Somewhere along the line, the outlet _is_ being set to such an object.
For humor value try replacing the send of testMethod with
NSLog(@"%@", whateverTheOutletNameIs);
Perhaps you'll recognize what's being printed out and that might help
you figure out when it's getting changed.

G

Reply to this Message

Wizumwalt@gmail.com - 27 Jun 2007 04:14 GMT

> For humor value try replacing the send of testMethod with
> NSLog(@"%@", whateverTheOutletNameIs);
> Perhaps you'll recognize what's being printed out and that might help
> you figure out when it's getting changed.

This is unbelievable, I can't for the life of me see anywhere's where
this thing is being set to anything else. I did the above and it
constantly thinks it's an NSCFArray.

It's just not being done. I have the outlet declaration in my *.h
file, I make a call to it in my *.m file. That's it. I have tons of
outlets all over my project but this one doesn't see the controller
that I connect it to.

I looked inside the *.nib files and nothing strange appeared to me
there. Is there anything that I can cleanup that a "clean all targets"
wouldn't clean? Something cached somewhere's? I just can't see
anything that would touch this outlet in my project to make it think
anything other than the class I connect it to.

Reply to this Message

Patrick Machielse - 27 Jun 2007 09:42 GMT

> I looked inside the *.nib files and nothing strange appeared to me
> there. Is there anything that I can cleanup that a "clean all targets"
> wouldn't clean? Something cached somewhere's? I just can't see
> anything that would touch this outlet in my project to make it think
> anything other than the class I connect it to.

Is it a 'typed' outlet, or is it type 'id'? Try setting the right type.
Have you tried re-importing/re-reading the file in IB?

patrick

Reply to this Message

Gregory Weston - 27 Jun 2007 12:42 GMT

> > For humor value try replacing the send of testMethod with
> > NSLog(@"%@", whateverTheOutletNameIs);
[quoted text clipped - 4 lines]
> this thing is being set to anything else. I did the above and it
> constantly thinks it's an NSCFArray.

An empty one, I assume, since you didn't have an "a-ha" moment?

The simple answer for why it "thinks" it's an NSCFArray is that it _is_
an NSCFArray. Object pointers are object pointers and you can shove a
pointer to any class type you like into any class pointer regardless of
what the declared type of that pointer is. The output you're getting is
saying it's a NSCFArray because it's asking the object at the pointer
what type it is and the object is saying "I'm an NSCFArray."

> It's just not being done. I have the outlet declaration in my *.h
> file, I make a call to it in my *.m file. That's it. I have tons of
> outlets all over my project but this one doesn't see the controller
> that I connect it to.

I'd really love to see the @interface for the class that contains the
pointer.

G

Reply to this Message

Wizumwalt@gmail.com - 28 Jun 2007 02:30 GMT

> The simple answer for why it "thinks" it's an NSCFArray is that it _is_
> an NSCFArray. Object pointers are object pointers and you can shove a
> pointer to any class type you like into any class pointer regardless of
> what the declared type of that pointer is. The output you're getting is
> saying it's a NSCFArray because it's asking the object at the pointer
> what type it is and the object is saying "I'm an NSCFArray."

I have no doubt that what it's saying, but that's just not my
intention and I don't see how it can be so.

> I'd really love to see the @interface for the class that contains the
> pointer.

---

#import <Cocoa/Cocoa.h>
#import "NetworkConfig.h"
#import "NetworkTopology.h"
#import "NetworkServer.h"

@class DataTableController;
@class GraphController;
@class NetworkDesignController;
@class NetworkOutlineController;
@class NetworkWizardController;

@interface AppController : NSObject <NetworkController>
{
    BOOL    createdOutlineFlag;
    int        createMode;
    int        runMode;

    IBOutlet DataTableController *testOutlet;
    IBOutlet NSButton *trainButton;
    IBOutlet NSButton *runButton;
    IBOutlet NSButton *stopButton;

    IBOutlet NSWindow *mainWindow;
    IBOutlet id mainTabSelection;
    IBOutlet id initControl;
    IBOutlet id startControl;
    IBOutlet id toolsToggle;

    IBOutlet id mainWindowMSEView;
    IBOutlet id trainedProgressIndicator;
    IBOutlet id trainedProgressValue;
    IBOutlet id trainedIterationsValue;

    IBOutlet DataTableController *tableController;
    IBOutlet GraphController *graphController;
    IBOutlet NetworkDesignController *designController;
    IBOutlet NetworkWizardController *wizardController;
    IBOutlet NetworkOutlineController *networkOutline;

    id <NetworkMethods> server;
    NSConnection *kitConnection;

    NetworkConfig *nnConfig;
    NSMutableArray *networks;

    NSString *networkSaveFile;
}

Reply to this Message

Gregory Weston - 28 Jun 2007 05:05 GMT

> > I'd really love to see the @interface for the class that contains the
> > pointer.
[quoted text clipped - 48 lines]
> NSString *networkSaveFile;
> }

Where's the rest of the interface, and which outlet is the one that's
giving you trouble?

Reply to this Message

Wizumwalt@gmail.com - 28 Jun 2007 05:34 GMT

The testOutlet and tableController are the outlets giving me problems.
testOutlet is just one that I added for debugging purposes. They both
point to the same class DataTableController which has a testMethod:.

---
#import <Cocoa/Cocoa.h>
#import "NetworkConfig.h"
#import "NetworkTopology.h"
#import "NetworkServer.h"

@class DataTableController;
@class GraphController;
@class NetworkDesignController;
@class NetworkOutlineController;
@class NetworkWizardController;

@interface AppController : NSObject <NetworkController>
{
    BOOL    createdOutlineFlag;
    int        createMode;
    int        runMode;

    IBOutlet DataTableController *testOutlet;
    IBOutlet NSButton *trainButton;
    IBOutlet NSButton *runButton;
    IBOutlet NSButton *stopButton;

    IBOutlet NSWindow *mainWindow;
    IBOutlet id mainTabSelection;
    IBOutlet id initControl;
    IBOutlet id startControl;
    IBOutlet id toolsToggle;

    IBOutlet id mainWindowMSEView;
    IBOutlet id trainedProgressIndicator;
    IBOutlet id trainedProgressValue;
    IBOutlet id trainedIterationsValue;

    IBOutlet DataTableController *tableController;
    IBOutlet GraphController *graphController;
    IBOutlet NetworkDesignController *designController;
    IBOutlet NetworkWizardController *wizardController;
    IBOutlet NetworkOutlineController *networkOutline;

    id <NetworkMethods> server;
    NSConnection *kitConnection;

    NetworkConfig *nnConfig;
    NSMutableArray *networks;

    NSString *networkSaveFile;
}

- (id) init;
- (void) awakeFromNib;
- (void) dealloc;

- (IBAction) networkCommands:(id) sender;
- (IBAction) readMenuItem:(id) sender;
- (void) newNetwork:(id) sender;
- (IBAction) runWizard:(id) sender;
- (IBAction) runNetwork:(id) sender;
- (void) trainNetwork;
- (IBAction) stopNetwork:(id) sender;
- (IBAction) saveNetwork:(id) sender;
- (IBAction) saveNetworkAs:(id) sender;
- (IBAction) showNetworkInfo:(id) sender;
- (void) loadNetwork;
- (void) setNetworkSaveFile:(NSString *) fileName;

- (void) updateIterations:(int) iterations;
- (void) updateTrained:(int) good maxValue:(int) max;
- (void) savePanelDidEnd:(NSSavePanel *) panel
    returnCode:(int) code contextInfo:(void *) info;

- (void) setServer:(id) anObject tag:(int) serverTag;
- (void) setServerProgress:(int) status;
- (void) setServerProgress:(double) newStatus finished:(BOOL) running
        tag:(int) theTag;
- (void) launchServerThreads;

- (IBAction) switchTabs:(id) sender;
- (void) windowControllerDidLoadNib:(NSWindowController *) controller;
- (void) populateTable:(NetworkConfig *) config;
- (void) openPanelDidEnd:(NSOpenPanel *) openPanel returnCode:(int)
returnCode contextInfo:(void *) context;

@end

Reply to this Message

David Phillip Oster - 27 Jun 2007 15:28 GMT

For what it is worth, I've seen outlets magically change to objects of
the wrong type when the referenced object is prematurely released, and
the runtime reuses that part of the heap for a new object. The outlet's
weak reference hasn't changed, but now points to a new object, with an
unexpected type.

Reply to this Message

Mac Forum / Programming / Mac Programming / June 2007

help getting outlet to work