Note in Objective-C

Create QR Code in Objective-C Note

There s much to know about classes and commands that is not explained here. Please read on; it will all make sense in time.

The commands in the dictionary appear along with a brief description, which is followed by the command s syntax, which also includes the parameters. The optional parameters appear in square brackets. The following is an example taken from the Finder s dictionary. The example shows the listing of the update command: update: Update the display of the specified object(s) to match their on-disk representation update reference -- the item to update [necessity boolean] -- only update if necessary (i.e. a finder window is open). default is false [registering applications boolean] -- register applications. default is true The description of the update command is great. You read it, and you have no doubt about what the command does. The required parameter for the command is the reference to the object you want to update.

The optional parameters are necessity, which is explained well, and registering applications, which . . . well, I have no idea what it s good for or what it does. The dictionary author either got a bit lazy or simply didn t know the answer either.

Although dictionaries are invaluable for any scripter, they are sometimes badly written and incomplete. They don t necessarily lack commands or classes, but many times dictionaries are written as an afterthought; dictionary authors sometimes just do not account for the immense difference a good dictionary can make to the scripter who tries to automate that application. The amount of detail and level of clarity invested in dictionaries are solely up to the dictionary authors, and the range of acceptable detail is high. For instance, when the properties are listed for a specific class, the dictionary usually mentions something in regard to the value that the property accepts. Some properties accept only a list, string, or number; some can accept only specific tokens defined by that application, such as the owner privileges property of the item class in the Finder. The properties can be read only, read write, write only, or none. Although the Finder s dictionary does list these options, some dictionaries lack basic information something that can make scripting frustrating. Another fact you can t tell by looking at a dictionary is which classes of objects accept which commands. For instance, the Finder dictionary contains the class window and the command duplicate, but that doesn t mean you can duplicate a window. How commands and classes interact is information you have to find in other places such as books, Internet lists, sample scripts that come with the application, or just good ol , late-night, trial-and-error experimentation.

Perhaps the most compelling part of application scriptability is its object model. The idea of an object model is that one object can contain a number of other objects, which can themselves contain other objects, and so on. An object that contains other objects is known as a container, and the objects it contains are described as being elements of that container. The number of elements can be anywhere from zero up. This type of hierarchy is called a containment hierarchy, since it describes which objects contain which elements and which objects contain which elements. Let s look at InDesign s object model as an example: the InDesign application object contains zero or more document elements. (As you know, InDesign allows you to have any number of documents open at the same time.) In turn, each document object contains its own child elements such as spreads, layers, and so on. Spreads can have many pages, and each page has text frames, guides, and so on. Like in some other applications, in InDesign you can ask for the object model in reverse as well; the parent of a specific text frame may be a specific page, and so on.