Collection class

A collection class stores objects of the same kind in a collection, where each item can be identified by an index. It's very similar to an C++ array.

Browser class 

A browser class is a bit similar to a collection class. The difference is that while the a collection will keep all its items like an array, the browser class will not store any items in a permanent location.

The browser class parses through the Finale database, one item at a time.

A browser class are more memory efficient than a collection class, but it can get more time-consuming if the same records need processing more than once.

At some occasions browser classes are a superior choice, for example:

  • When the data objects need to be processed only once

  • When searching the Finale database for specific information

The Lock Page Layout Example shows the browser class in action. Here the browser approach was chosen, since each page only need to be processed once.

The most common method to use a browse class is with the ForEach method, since a browser class doesn't provide as many iteration methods as a collection class.


Iterator handler

Iterator handlers were inspired by the code block (or closure) concept in the great Ruby script programming language. They provide a mechanism to separate functionality from data storage in "collection-type" classes. With iterator handles, you first decide in what way to parse the collection, then you "send" the processing functionality to that particular parser.

Iterator handlers are used by both collection classes and browser classes. If the implementation of the iterator handler doesn't assume that the supplied data is stored in a certain way, iterator handles can be used interchangeably by both collection classes and browser classes.

Please note that iterator handlers are not covered by the type-safe linkage in C++. It's up to the programmer to make sure that the object type passed to the iterator handler is a known type. For example, sending measure objects to an iterator handle that assumes staff objects will most likely crash.