Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Use different window than File Owner's in NIB
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use different window than File Owner's in NIB

On Jul 5, 2004, at 7:42 PM, David Bainbridge wrote:
but I was hoping for a less obtrusive way that didn't require the headache of maintaining multiple files on disk and in the project.. looks silly having "...controller2.nib", "...controller3.nib", then decide #2 is the one you want and have to go back and rename that nib to the "correct" name..

I don't understand, but you are clearly unhappy with this solution. If you have 3 ui designs for a complicated window, a single nib file with all of these objects will be difficult to maintain. I am uncomfortable having many objects in any given nib file, so 3 designs for a complicated window all in a single nib file is not something I would do. If you are comfortable with it though, that is what you should do.

the windows do not require to be loaded at the same time...

If your two windows are both in a single nib file, they will both get loaded (as defined by loadNibNamed:) but they won't get loaded (as in loaded/shown/orderedFront to screen). I have heard a few requests for loading nib files in parts; do you want only part of your nib file to get loaded?

just so someone can view one then the other.. I would have thought this was a somewhat common need since the "test interface" in IB only goes so far with complicated windows...

InterfaceBuilder is a great tool and was designed to take advantage of a dynamic language and a framework of objects that can archive/unarchive. Since IB can only test interface behavior of code it is linked with, it can test resizing and simple action messages, but is unable to test project code that is not linked into a loaded palette.

I have seen a few palettes over 14+ years of working with InterfaceBuilder that push far far further than simply testing resize springs. If you want better test interface behavior, you can look into writing a palette and try promoting more palette writing (personally, I don't usually like palettes, but that is a long story that is likely to change).

I do have some more suggestions:

- Localization. Pretend your design iterations are localizations
- Cvs. Check out multiple copies of source
- setWindow. Use a simple setWindow: style controller
- Controller. Change your design to use a data manager/controller/owner

Localization. If you put your design iterations into a localized lproj directory, you can switch to say French and load your nib file. This idea also adds files to your filesystem, but does not require changing a file name which is probably a code change. So, your headache is a little different. This solution has an advantage that users can easily switch between your different designs.

Cvs. If your source is in some kind of source management system like cvs, you can check out multiple versions and compile two different applications that have your ui design variations. This solution has some extra clutter involved, but it is easy to do, does not require any code or nib changes after you decide, and is easy to check in both versions after you make a decision (check in bad, check in good, keep both versions in cvs).

setWindow. If your change is as simple as choosing which window to show, which won't work if your controller, acting as file's owner, requires outlet connections to do its controlling. If it is just a window, a simple controller could choose which window then call setWindow: on your file's owner object.

Controller. As a design, using a window controller to control views within a window has both advantages and disadvantages. This design is well documented in both Apple docs and in various Cocoa books, it puts all of your code into a single object which can simplify where your code is and help reduce how many objects are in a "complicated" window. But, it relies on using a file's owner object to have connections to view objects in your nib file.
A different design could use a file's owner object that provides data to a nib instantiated controller that handled interacting with views within your nib file. This file's owner would be more like a data manager (if it used a data model instance to relay data), or a data owner (if it owned this data), or a data controller (like an NSDocument, but this design would likely require outlets and not be a real change). Your nib-instantiated controller would have an outlet to your file's owner, get what data it needed and then interact with your ui. With this design, it would be easy to instantiate multiple controllers to control multiple windows.



-jim



BTW, If there is a better solution available from a Java or C# tool, I'd am curious to hear it; these tools, in my experience, focus more on code generation and rely on their ide to do anything like test interface.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Use different window than File Owner's in NIB (From: David Bainbridge <email@hidden>)
 >Re: Use different window than File Owner's in NIB (From: James DiPalma <email@hidden>)
 >Re: Use different window than File Owner's in NIB (From: David Bainbridge <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.