Realizing I'm not making myself very clear.
I have two questions. We have an application called WindowWindow with
two classes.
AppController.m (which is linked as a delegate of Files Owner)
SecondWindow.m (as a subclass of NSWindowController with an init
method calling self = [super initWithWindowNibName:@"SecondWindow"
owner:self];)
1) So, how exactly is SecondWindow.m going to know about and act upon
a NSButton or NSTextField within in the SecondWindow.xib?
2) Shouldn't [secondWindow close] be working just as [secondWindow
window] is working? For some reason, [secondWindow close] isn't
working at all. At least the documentation says this is how it's done.
//
// SecondWindow.h
// WindowWindow
//
@interface SecondWindow : NSWindowController {
}
- (id)init;
@end
//
// SecondWindow.m
// WindowWindow
//
#import "SecondWindow.h"
@implementation SecondWindow
- (id)init {
self = [super initWithWindowNibName:@"SecondWindow" owner:self];
if (self != nil) {
NSLog(@"SecondWindow super initWithWindowNibName
success...");
} else {
NSLog(@"SecondWindow had trouble loading/init...");
}
return self;
}
//
// AppController.m
// WindowWindow
//
#import "AppController.h"
@implementation AppController
@synthesize secondWindow;
- (void)applicationDidFinishLaunching:(NSNotification *)notification {
secondWindow = [[SecondWindow alloc] init];
[secondWindow window]; // this activates the window. Documentation
says it should and it does.
// I placed a 3 second NSTimer here just to be sure it wasn't a
timing issue.
[secondWindow close];
}
On Jul 7, 2011, at 8:03 AM, Kevin Muldoon wrote:
Yes, that was a typo. My email was acting weird.
So, I'm not entirely certain Wim. I kinda feel I'm caught between
the xCode 3 way of doing things and xCode 4 (and all the variants in
between). Seems Obj-C/Cocoa is changing so fast I'm just not sure
which way is right.
Specifically, when using Andrew Stones method, I would expect I
could access the UI elements of the window...uhm...somehow. That I
could call the object I attached to the nib and hide the window. Or
get the string value of a NSText field. So far, I'm stumped.
There was an xCode example which I think would clear things up for
me but this no longer exists. Possibly for good reason.
/Developer/Examples/InterfaceBuilder/SimpleMultiWindow
Anyway, I'd be happy to raw nib load as I was leaning towards or
even NSWindowController...I just want to remove my working code from
my AppController (or whatever it's called in later xCodes) and place
it where it makes more sense. So it will have a semblance of
reusability rather than entwined into 'main'.
Thanks for the responses guys. Maybe google will be kinder to me as
I dive back into it. If ya'll have any places you'd like to point
me, I'll happily check it out.
On Wed, Jul 6, 2011 at 9:11 PM, Wim Lewis <w...@omnigroup.com> wrote:
On 6 Jul 2011, at 2:43 PM, Kevin Muldoon wrote:
> I'm seeking to do a copyObject class that has it's own progress
window. So, I'm doing my research and I see a technique for loading
a nib with an object, like so...
>
> MyDocument *myDocument = [[MyDocument alloc] init];
> [NSBundle loadNibNamed:@"MyDocument" owner:myDocument];
> [owner:myDocument doAnInterestingMethodToTheWindow];
> Now, this looks like it's the compartmentalization I want when
building UI!
>
> Andrew Stone takes things even father.
http://www.stone.com/The_Cocoa_Files/Doing_Objects_Right.html
>
> So, I've been banging away at this for 10+ hours and things aren't
working quite as expected. Given all the changes in xCode/Cocoa in
the last 2 years, I'm wondering if I'm looking at antiquated
techniques and need to be looking elsewhere for handling multiple
windows.
That looks right to me (assuming the third line's owner: is a typo).
Though as Jens Alfke says, if you make your owner object a subclass
of NS{View,Window}Controller it will take care of some housekeeping
for you.
In what way is it not working as expected? Are you checking the
results of loadNibNamed:, etc? Are your owner object's outlets being
set to the correct non-nil objects instantiated from the nib?
Kevin Muldoon
e: caoimgh...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
