Re: how to manage multiple non-document windows
On Apr 24, 2008, at 5:01 PM, Ken Thomases wrote: On Apr 24, 2008, at 6:39 PM, Steve Christensen wrote: I'm rewriting an old legacy app in Cocoa and have run into a stumbling block. The app is supposed to support having multiple windows open, but the window content is unrelated to the concept of a document - which is the normal multiple window model. Instead the windows provide a UI to perform specific calculations, among other things. An example of what I'm looking for would be if you had a version of the Calculator application where you could create multiple calculator windows so you could leave several calculations open simultaneously, if that makes sense. When I start up the app, an instance of the window is created, but I can't figure out how to get it to repeat the process in response to selecting New from the File menu. I've found a bunch of info on multiple document windows, or a single non-doc window plus a preferences window, but nothing on instantiating multiple non- document windows. Did I just miss something basic, or is all of the magic really focused on NSDocumentController, etc.? If you're going to instantiating a window from a nib multiple times, it should generally be in the nib by itself. Well, the nib can have other objects which accompany the window, like NSController subclasses. Then, you load the nib once for each window that you need to instantiate. It's quite helpful to use NSWindowController (or custom subclass) objects to manage each nib, its loading, and the resulting window. Typically, the NSWindowController is not contained in the nib. Rather it is instantiated to manage the loading of the nib from the outside. It is often the File's Owner of the nib. I put both the window and NSWindowController subclass in MainMenu.nib since some of the menu items control behavior in the window (and some of the window's current state is reflected in the menus. So I wouldn't think that you'd want to reload the nib for that case, right? I've tried using -[NSWindowController initWithWindowNibName:owner:] to create a new controller instance (in response to FileNew), figuring that it'd drag the associated window along, but the controller's _window ivar is nil, so obviously that's not working. Is it just going to be easier for me to go the NSDocument, etc., route and say that I have a document that I'm going to load (wink, wink) in order to better fit within what appears to be the expected multiple window model? I also just noticed that when I close one of these windows (configured with release on close), the controller still hangs around, but that's another issue... ___ 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 [EMAIL PROTECTED]
Re: how to manage multiple non-document windows
Le 25 avr. 08 à 21:06, Steve Christensen a écrit : On Apr 24, 2008, at 5:01 PM, Ken Thomases wrote: On Apr 24, 2008, at 6:39 PM, Steve Christensen wrote: I'm rewriting an old legacy app in Cocoa and have run into a stumbling block. The app is supposed to support having multiple windows open, but the window content is unrelated to the concept of a document - which is the normal multiple window model. Instead the windows provide a UI to perform specific calculations, among other things. An example of what I'm looking for would be if you had a version of the Calculator application where you could create multiple calculator windows so you could leave several calculations open simultaneously, if that makes sense. When I start up the app, an instance of the window is created, but I can't figure out how to get it to repeat the process in response to selecting New from the File menu. I've found a bunch of info on multiple document windows, or a single non-doc window plus a preferences window, but nothing on instantiating multiple non- document windows. Did I just miss something basic, or is all of the magic really focused on NSDocumentController, etc.? If you're going to instantiating a window from a nib multiple times, it should generally be in the nib by itself. Well, the nib can have other objects which accompany the window, like NSController subclasses. Then, you load the nib once for each window that you need to instantiate. It's quite helpful to use NSWindowController (or custom subclass) objects to manage each nib, its loading, and the resulting window. Typically, the NSWindowController is not contained in the nib. Rather it is instantiated to manage the loading of the nib from the outside. It is often the File's Owner of the nib. I put both the window and NSWindowController subclass in MainMenu.nib since some of the menu items control behavior in the window (and some of the window's current state is reflected in the menus. So I wouldn't think that you'd want to reload the nib for that case, right? I've tried using -[NSWindowController initWithWindowNibName:owner:] to create a new controller instance (in response to FileNew), figuring that it'd drag the associated window along, but the controller's _window ivar is nil, so obviously that's not working. Is it just going to be easier for me to go the NSDocument, etc., route and say that I have a document that I'm going to load (wink, wink) in order to better fit within what appears to be the expected multiple window model? I also just noticed that when I close one of these windows (configured with release on close), the controller still hangs around, but that's another issue... It will probably be easier for you to understand how nib works. Going the NSDocument way whithout nowledge of what append will not help you. You don't have to add an instance of your window controller to the nib. First create a new nib file. Select the nib owner and set it's class to your window controller class. Then bind the owner window outlet to the Window object. and bind your control to the owner. And finaly, create a controller instance using -[NSWindowController initWithWindowNibName:]; (it sets the owner to self by default) Now, for your menu items in MainMenu, bind them to the FirstResponder object. So the action will always be send to the Window controller instance that own the front window. ___ 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 [EMAIL PROTECTED]
Re: how to manage multiple non-document windows
On Apr 25, 2008, at 12:45 PM, Erik Verbruggen wrote: On 25 Apr 2008, at 20:06, Steve Christensen wrote: I put both the window and NSWindowController subclass in MainMenu.nib since some of the menu items control behavior in the window (and some of the window's current state is reflected in the menus. So I wouldn't think that you'd want to reload the nib for that case, right? Yes, you will want to reload the nib to get a new window. However, no, you don't want that for the menu bar. So you should move the window to a different nib file. Unfortunately, that will give you the excitement of having to update the menu status according to the selected window: And if I move the window and window controller out of the main nib, I'm no longer given an option for targets associated with my window controller (the first responder doesn't list my controller IBActions) when trying to wire up all the menu items. This was likely why I just put them into the main nib in the first place. ___ 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 [EMAIL PROTECTED]
Re: how to manage multiple non-document windows
Le 26 avr. 08 à 01:44, Steve Christensen a écrit : On Apr 25, 2008, at 12:45 PM, Erik Verbruggen wrote: On 25 Apr 2008, at 20:06, Steve Christensen wrote: I put both the window and NSWindowController subclass in MainMenu.nib since some of the menu items control behavior in the window (and some of the window's current state is reflected in the menus. So I wouldn't think that you'd want to reload the nib for that case, right? Yes, you will want to reload the nib to get a new window. However, no, you don't want that for the menu bar. So you should move the window to a different nib file. Unfortunately, that will give you the excitement of having to update the menu status according to the selected window: And if I move the window and window controller out of the main nib, I'm no longer given an option for targets associated with my window controller (the first responder doesn't list my controller IBActions) when trying to wire up all the menu items. This was likely why I just put them into the main nib in the first place. You can add methods and Outlet manualy to a class in IB. In the Identity tab of the inspector, there is the class name, and the list of methods and outlets, both with a +button. Add your methods to the first responder and then you will ba able to bind them. ___ 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 [EMAIL PROTECTED]
Re: how to manage multiple non-document windows
On Apr 25, 2008, at 5:51 PM, Jean-Daniel Dupas wrote: Le 26 avr. 08 à 01:44, Steve Christensen a écrit : On Apr 25, 2008, at 12:45 PM, Erik Verbruggen wrote: On 25 Apr 2008, at 20:06, Steve Christensen wrote: I put both the window and NSWindowController subclass in MainMenu.nib since some of the menu items control behavior in the window (and some of the window's current state is reflected in the menus. So I wouldn't think that you'd want to reload the nib for that case, right? Yes, you will want to reload the nib to get a new window. However, no, you don't want that for the menu bar. So you should move the window to a different nib file. Unfortunately, that will give you the excitement of having to update the menu status according to the selected window: And if I move the window and window controller out of the main nib, I'm no longer given an option for targets associated with my window controller (the first responder doesn't list my controller IBActions) when trying to wire up all the menu items. This was likely why I just put them into the main nib in the first place. You can add methods and Outlet manualy to a class in IB. In the Identity tab of the inspector, there is the class name, and the list of methods and outlets, both with a +button. Add your methods to the first responder and then you will ba able to bind them. That did it! Thank you so much for the pointer. steve ___ 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 [EMAIL PROTECTED]
