Re: Loading Nibs which are self-ref
Ahh. Yes. I see what you're saying. And maybe you see where I was confused. This GUI approach to hooking up code/UI is nifty, but extremely difficult to explain/comprehend. As to xCode2,xCode3,xCode4, you'll notice one of the first things we used to have to do was create an AppController, then create an NSObject in IB and then make it a subclass of AppController and then hook it as a delegate of File Owner. That was annoying, and in later additions of xCode, the AppDelegate is automagically created and xCode encouraged developers to access UI elements via separate Controller objects. This makes sense and I wanted to do just that, but you'll notice nobody ever mentions subclassing the File's Owner of SecondWindow.nib to the SecondWindow.m the window is supposed to be controlled by. As if to say this would be explaining how exactly to breathe. On Jul 7, 2011, at 5:36 PM, Jens Alfke wrote: > > On Jul 7, 2011, at 12:45 PM, Kevin Muldoon wrote: > >> Can I (or should I) hook up File's Owner as I would a subclass of >> NSWindowController? Thereby skipping creating a new object->subclassing as >> SecondWindow? That seems 'right'. That nicely separates my code from my UI, >> making it (bit) more portable, but may be contributing to unresponsive >> behavior. > > I’m sorry, I don’t understand what you’re asking. The class of the Files’ > Owner object should be set to your NSWindowController subclass. You don’t add > any custom object to the nib for the window controller. > > The “File’s Owner” pseudo-object in the nib is a placeholder for the > pre-existing object specified as the owner when the nib is loaded; it’s not > an object loaded by the nib. The purpose of that object is so that outlets in > that object can be hooked up, and so objects from the nib can be pointed at > it. > >> For instance...This code will update NSTextField with text... >> >> secondWindow = [[SecondWindow alloc] init]; >> [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I >> am very glad to meet you."]; >> [secondWindow showWindow:secondWindow]; >> >> This code will NOT update NSTextField with text... >> >> secondWindow = [[SecondWindow alloc] init]; >> [secondWindow showWindow:secondWindow]; >> [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I >> am very glad to meet you.”; > > Both of those should work correctly. > > —Jens 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
Re: Loading Nibs which are self-ref
Well, I suppose that's what attracted me to this technique. When we call... > secondWindow = [[SecondWindow alloc] init]; The init method within SecondWindow does this... self = [super initWithWindowNibName:@"SecondWindow" owner:self]; Meaning the Files Owner is SecondWindow -- because it was initialized that way. Now, if common practice is to make the new nib in IB, then create a new NSObject instance within that nib and then subclass said instance to SecondWindow, I'm not sure what benefit initWithWindowNibName@"nameOfNib" owner:instantiatedObject would have in the real world. It is interesting to note that subclassing FileOwer to SecondWindow actually does work. Outlets and Actions are seen and can be wired up in IB, forgiving any oddness I described which may or may not be odd at all. Am I thinking too differently here? On Jul 7, 2011, at 5:36 PM, Jens Alfke wrote: > > On Jul 7, 2011, at 12:45 PM, Kevin Muldoon wrote: > >> Can I (or should I) hook up File's Owner as I would a subclass of >> NSWindowController? Thereby skipping creating a new object->subclassing as >> SecondWindow? That seems 'right'. That nicely separates my code from my UI, >> making it (bit) more portable, but may be contributing to unresponsive >> behavior. > > I’m sorry, I don’t understand what you’re asking. The class of the Files’ > Owner object should be set to your NSWindowController subclass. You don’t add > any custom object to the nib for the window controller. > > The “File’s Owner” pseudo-object in the nib is a placeholder for the > pre-existing object specified as the owner when the nib is loaded; it’s not > an object loaded by the nib. The purpose of that object is so that outlets in > that object can be hooked up, and so objects from the nib can be pointed at > it. > >> For instance...This code will update NSTextField with text... >> >> secondWindow = [[SecondWindow alloc] init]; >> [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I >> am very glad to meet you."]; >> [secondWindow showWindow:secondWindow]; >> >> This code will NOT update NSTextField with text... >> >> secondWindow = [[SecondWindow alloc] init]; >> [secondWindow showWindow:secondWindow]; >> [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I >> am very glad to meet you.”; > > Both of those should work correctly. > > —Jens 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
Re: Loading Nibs which are self-ref
On Jul 7, 2011, at 12:45 PM, Kevin Muldoon wrote: > Can I (or should I) hook up File's Owner as I would a subclass of > NSWindowController? Thereby skipping creating a new object->subclassing as > SecondWindow? That seems 'right'. That nicely separates my code from my UI, > making it (bit) more portable, but may be contributing to unresponsive > behavior. I’m sorry, I don’t understand what you’re asking. The class of the Files’ Owner object should be set to your NSWindowController subclass. You don’t add any custom object to the nib for the window controller. The “File’s Owner” pseudo-object in the nib is a placeholder for the pre-existing object specified as the owner when the nib is loaded; it’s not an object loaded by the nib. The purpose of that object is so that outlets in that object can be hooked up, and so objects from the nib can be pointed at it. > For instance...This code will update NSTextField with text... > > secondWindow = [[SecondWindow alloc] init]; > [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I > am very glad to meet you."]; > [secondWindow showWindow:secondWindow]; > > This code will NOT update NSTextField with text... > > secondWindow = [[SecondWindow alloc] init]; > [secondWindow showWindow:secondWindow]; > [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I > am very glad to meet you.”; Both of those should work correctly. —Jens___ 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
Re: Loading Nibs which are self-ref
My God that knowledge was hard won. Still, I'm getting some unresponsive behavior. The usual way: You declare the button as an IBOutlet in SecondWindow’s instance variable declarations, and wire it up to the actual control in IB. Yes, this works now that I have wired window to NSWindowController via inherited 'window' outlet and set delegate to controller. I just wasn't grokking. Partially because of this next question. Can I (or should I) hook up File's Owner as I would a subclass of NSWindowController? Thereby skipping creating a new object- >subclassing as SecondWindow? That seems 'right'. That nicely separates my code from my UI, making it (bit) more portable, but may be contributing to unresponsive behavior. For instance...This code will update NSTextField with text... secondWindow = [[SecondWindow alloc] init]; [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I am very glad to meet you."]; [secondWindow showWindow:secondWindow]; This code will NOT update NSTextField with text... secondWindow = [[SecondWindow alloc] init]; [secondWindow showWindow:secondWindow]; [secondWindow setStringValueOfMyTextField:@"Hello! I am SecondWindow! I am very glad to meet you."]; Thanks for the assistance. I'm looking forward to getting to the part which started me doing this part. On Jul 7, 2011, at 12:17 PM, Jens Alfke wrote: On Jul 7, 2011, at 5:03 AM, Kevin Muldoon wrote: I don’t see a difference. Xcode is just a tool; it doesn’t dictate the ways you develop code. If anything, it’s the releases of the OS that introduce and deprecate ways of doing things. And both NSWindowController and manual nib loading have been around forever. 1) So, how exactly is SecondWindow.m going to know about and act upon a NSButton or NSTextField within in the SecondWindow.xib? The usual way: You declare the button as an IBOutlet in SecondWindow’s instance variable declarations, and wire it up to the actual control in IB. 2) Shouldn't [secondWindow close] be working just as [secondWindow window] is working? Actually calling -window isn’t the right way to show the window. All it does is cause the window to be loaded; this may or may not cause the window to be visible depending on how you set the ‘visible at launch time’ flag on the window in IB. Usually you want this flag to be false so that NSWindowController can customize the window bounds (tiling or restoring) before it’s displayed. If you want to show the window, call -showWindow:. For some reason, [secondWindow close] isn't working at all. At least the documentation says this is how it's done. Hm. My first guess is that you didn’t wire up the window to the NSWindowController’s inherited ‘window’ outlet. Lots of things won’t work unless you do this. (You also have to wire up the window’s delegate to the controller.) —Jens 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
Re: Loading Nibs which are self-ref
On Jul 7, 2011, at 5:03 AM, Kevin Muldoon wrote: > 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). I don’t see a difference. Xcode is just a tool; it doesn’t dictate the ways you develop code. If anything, it’s the releases of the OS that introduce and deprecate ways of doing things. And both NSWindowController and manual nib loading have been around forever. > 1) So, how exactly is SecondWindow.m going to know about and act upon a > NSButton or NSTextField within in the SecondWindow.xib? The usual way: You declare the button as an IBOutlet in SecondWindow’s instance variable declarations, and wire it up to the actual control in IB. > 2) Shouldn't [secondWindow close] be working just as [secondWindow window] is > working? Actually calling -window isn’t the right way to show the window. All it does is cause the window to be loaded; this may or may not cause the window to be visible depending on how you set the ‘visible at launch time’ flag on the window in IB. Usually you want this flag to be false so that NSWindowController can customize the window bounds (tiling or restoring) before it’s displayed. If you want to show the window, call -showWindow:. > For some reason, [secondWindow close] isn't working at all. At least the > documentation says this is how it's done. Hm. My first guess is that you didn’t wire up the window to the NSWindowController’s inherited ‘window’ outlet. Lots of things won’t work unless you do this. (You also have to wire up the window’s delegate to the controller.) —Jens___ 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
Re: Loading Nibs which are self-ref
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 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
Re: Loading Nibs which are self-ref
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 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?
>
>
>
___
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
Re: Loading Nibs which are self-ref
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?
___
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
Re: Loading Nibs which are self-ref
On Jul 6, 2011, at 2:43 PM, Kevin Muldoon wrote: > 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! I’ve rarely had to do ‘raw’ nib loading like this. Generally I make my class inherit from NSWindowController or NSViewController, which handle that level for me. —Jens___ 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
Loading Nibs which are self-ref
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. 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
