Programmatically supply tab view with views?

Scripting Forums AppleScriptObjC and Xcode
#1

Has anyone been able to programmatically supply a tab view with each of its views as the user selects each tab view item?

The documentation says that it is better to keep each window in its own nib “ does that also go for each view of a tab view, in effect treating each view as a separate window?

If the answer is “yes” can it be done in both Obj-C and ApplescriptObjC?

Thanks in advance.

#2

I’m not sure what you mean here.

No. It’s also not necessarily good advice for ASObjC projects.

#3

Thanks, Shane. I read that note in your book about not necessarily keeping every window in its own xib in AppObjC projects. I raised this question here because an Obj-C developer friend told me that you get better memory allocation and performance out of an app that does keep windows in their own xibs. He suggested also splitting up a tab view into multiple xibs containing views that get loaded/displayed (triggered) when the user clicks between tabs. I was scratching my head about how to implement that in AppObjC. I’m taking your advice and going the standard route.

Thanks.

#4

In an ideal world, lazy-loading usually gives the best user experience, and obviously doesn’t use memory unless necessary. But ASObjC is not the ideal world; it’s one of compromises. You may even find that the extra startup time and memory taken to load the extra AppleScript class required, and build its Objective-C equivalent class, outweighs any potential savings. (I’m not saying it does, just that the issue is more complex.)

I also think worrying about the time taken to load a typical handful of tabs on modern computers verges on premature optimization.

#5

If performance was an issue, then you wouldn’t use nibs at all and create everything on the fly with code (Like FireFox). As for memory allocation, it’s sometimes better to allocate memory only when needed. If you have one big nib file the initialization and allocation is a longer process and you’re using memory that the user doesn’t use. The upside is that after the application is running and loaded, it will all run faster. Many applications does have multiple nibs but are all loaded at startup of the application to make the application run smoother, however they need a much longer loading time.

We seen many professional software that doesn’t follow guidelines but only their own, they need to run on multiple platform so it’s a compromise between different platform. But if you would ask if that is bad software, or bad programming the answer would be no. These guidelines are written down to put you as an developer in the right direction, but making a sidestep from the mainstream doesn’t directly mean bad programming. It just requires that you know what your are doing and not just messing around.

#6

Perhaps the question I should be asking is more general:

Is it even possible to rewrite a very large Applescript Studio project (referring to my own) that has over one hundred windows (contained in some 70+ nibs) as an ApplescriptObjC project (with minimal Obj-C, which is out of the scope of my near-term abilities) that maintains a similar nib structure? I have found that a nib starts getting very difficult to work with when too many windows, views, interface objects are placed in it.

If it is possible, any clues as to where to start learning how to implement it? It appears like it would involve methods like initWithWindow:, initWithNibName:, etc.

Thanks.

#7

Yes, it’s possible. For each window .xib you would create an AppleScript subclass of NSWindowController. In each, you would include something like this:

on init()
	continue initWithWindowNibName:"NameOfNib"
end init

So when you initialize an instance of your controller, it loads the nib and makes itself the nib’s owner. (You also need to set the class of the .xib’s file’s owner to your new class, so you can make connections in the interface).

You can set stuff up in the window by overriding awakeFromNib(), windowWillLoad() and windowDidLoad().

Then to show the window, you create a new instance of your window controller, probably in your app delegate. You tell it to showWindow() if the window isn’t set to Visible at Launch.

#8

Hugely helpful “ thanks. It appears that you already answered this same question in detail on 11-21-2009. Your patience with us neophytes is humbling. Thanks again.