Interface Builder – deferred and one-shot?

[patrick99e99]

Can anyone tell me what these mean?

-patrick

[Bruce_Phillips]

Documentation

[jobu]

If you’re not too familiar with the apple docs or with obj-c you may be a bit lost looking through the cocoa pages for clear answers. Although they have high-profile options in the window info pane, they’re actually just two small settings that some developers… primarily those doing cocoa programming, I would think… might have a clear use for.

Deferred…

@Apple Doc's

The flag argument determines whether the window server creates a window device for the new object immediately. If flag is YES, it defers creating the window until the receiver is moved onscreen. All display messages sent to the NSWindow or its NSViews are postponed until the window is created, just before it’s moved onscreen. Deferring the creation of the window improves launch time and minimizes the virtual memory load on the window server.
(from method description of “initWithContentRect:styleMask:backing:defer:”)

Essentially, deferring is used to wait until your window is completely drawn for before application messages and events are sent to it. As it says, it may increase launch time, but this is meant more for cocoa development than ASS development, so you may or may not see any changes or imporovements. I personally don’t ever mess with the default setting for the deferred flag… but I’m a creature of habit so I may not have a clue, 'eh?

One-shot…

@Apple doc's

Sets whether the window device that the receiver manages should be freed when it’s removed from the screen list (and another one created if it’s returned to the screen) to flag. Freeing the window device when it’s removed from the screen list can result in memory savings and performance improvement for NSWindows that don’t take long to display. It’s particularly appropriate for NSWindows the user might use once or twice but not display continually. The default is NO.

One shot windows can descrease your memory usage to some degree, but you have to be careful when you use them and how. By setting your window as one-shot, you allow it to be released after it is closed. By this, I mean that when you click the close button of the window or programmatically close it, it is sent away entirely from the windows in memory. It needs to be completely reloaded and redrawn for it to be displayed again, which can take some time for complex windows with lots of commands connected to them. For tiny windows that are infrequently used (such as prefs windows or registration windows) this can clean up your code and memory use a bit. Again, using this is more for good practice than a useful tool for ASS developers, usually. Realistically, if the window is so small that reloading it is practical, saving it in the memory won’t really be an issue for today’s computers. If your window’s a pretty intense memory hog, then using the one-shot flag may allow you to only load it when it’s absolutely necessary to have in memory, but you’ll have to weigh whether the load time is reasonable or not when redrawing the window after it’s been closed. Honestly, if you have a good reason to mess with their settings you’ll probably find out when or when not to use them, and then they’ll be of some value to you.

Hope that helps,
j