Animating Progress Bars

Progress bars are a little more complicated than we have seen so far. They can be set to animate themselves on a separate thread, which means they can update without repeated calls to the window to displayIfNeeded(). We have not introduced this animation before because it adds another factor that can complicate understanding of the whole problem of a responsive interface. But it does result in a much smoother display, so it is worth using.

The animation is turned on by a method called setUsesThreadedAnimation:. The documentation for this method says: “Sets a hint as to whether the receiver should implement animation of the progress indicator in a separate thread.” And later: “This value is only a hint and may be ignored.” In practise, my applications always take the hint, but you have been warned.

The documentation also says: “If the application becomes multithreaded as a result of an invocation of this method, the application’s performance could become noticeably slower.” Again, I have seen no sign of such a problem, although it might be more of an issue on a single-core Mac.

There are two ways you can implement this. The first way is in code. You will need to add a property set to missing value to your script, something like:

property progressBar : missing value

In Interface Builder connect it as an outlet for the progress bar (Control-click on the blue cube representing the script, and then drag from the circle next to progressBar to the bar itself). Then add a statement calling the method on the progress bar, like this:

tell progressBar to setUsesThreadedAnimation_(true)

You could put this somewhere near the start of the doProcess_ handler, but because it only needs to be called once, you could put it in the applicationWillFinishLaunching_ handler instead.

You can also get the same result in Interface Builder, without any code. Click on the progress bar and go to the Identity panel of the Inspector. If necessary, disclose the User Defined Runtime Attributes section. Click on the + button, and change the Key Path of the new entry to usesThreadedAnimation. The Type should be Boolean and the Value checked. Notice that you enter usesThreadedAnimation and not setUsesThreadedAnimation — usesThreadedAnimation is the property you wish to change.

Setting the progress bar to animate using Interface Builder

You can now save and go back to Xcode to test, but you might get a surprise: a sheet like the one shown below will probably appear, with the choice of Cancel, Save, and Review Issues. If you click on Review Issues, you will see a message that “User defined runtime attributes cannot be used with Interface Builder versions prior to 3.2”. This is a problem caused by the standard project template we use to make new projects: it is set to use a .xib file format that is backwards-compatible with older versions of Interface Builder, which did not have this ability.

The dialog you will probably get when you go to save in Interface Builder

Because we are unlikely to use these versions of Interface Builder, we can change the Development Target in the menu in the dialog to Default - Interface Builder 3.2, and when we do so, the error disappears and we can save.

Whether you use the code changes or Interface Builder, you will see that the resulting progress bar is much less jerky.

The Interface Builder error dialog: changing the Development Target will allow you to save the modified .xib file