Here are details about things you can do in an explorer view.

• Move a listing into a script. Individual lines of an explorer can be copied or dragged into a script. (Drag from the first column.) In a dictionary’s explorer, an alternative is to choose Dictionary > Paste Tell (or use the Paste Tell button in the toolbar). If what you copy into your script in this way is an object reference, it will be conveniently wrapped in a tell block if necessary.

You can also copy from the Value column. For example, instead of “album of file track 1 of playlist 6 of source 1”, you might like to paste “Stokes Eastern Birds” into your script. To do so, use the contextual menu and choose Copy Value, or hold Shift and choose Edit > Copy. Then paste wherever you want the value to go.

• Change a value. A value is writeable, and can be changed, unless it is badged with the crossed-out pencil icon () indicating that it is not writeable. Select the desired line and press Return (or Enter), or choose Edit Value from the contextual menu. The entry in the Value column will become editable, and you can change it. When you’re done, press Enter to set your change, or press Esc to cancel and leave the value untouched. Be careful! If what you are exploring is an object belonging to an external application, you are changing the actual value of an actual property of an actual object in the actual application! In the illustration above, the album property is an example.

• Change an enumerated value. If a value has little up-and-down arrows () to its left, it’s an editable enumeration. The arrows are a popup menu, and you can click them to get the menu and change the value (or see what the other possibilities are). In the illustration below, the shuffle and song repeat properties are examples.

• Change an element specifier. Element collections have little up-and-down arrows () at the right end of the left column. These allow you to change the element specifier used to gather the collection. By default, we get every whatever-it-is (for example, the list of sources was gathered by asking for every source). With the popup menu, you can get a different range or an individual element. The screen shot below shows how you can change from every source to the particular source named “Library”.

• Get a class definition. To learn more about a class (as opposed to an object), use the contextual menu and choose Show Definition. For example, if I control-click on the sources line, in the illustration above, and choose Show Definition, the window switches to Dictionary view with the source class selected.

• Refresh the explorer. An explorer is not live all the time. Information is gathered when you initially open the explorer and when you expand a triangle. If the situation in the target application changes, the explorer view information will need refreshing. To refresh it, select a line and choose Dictionary > Reload (or choose Reload from a line’s contextual menu). That line, and everything exposed that’s hierarchically deeper, will be gathered afresh. (To refresh the whole window, hold down the Option key as you choose Dictionary > Reload. But be careful, since Script Debugger may have to ask the target application for a lot of information.)

• Generate a separate viewer window. To focus in on a particular entity, double-click it. (Alternatively, select the entity and control-click it, and in the contextual menu, choose Open Viewer.) This creates a new viewer window showing the entity’s value.

You might wish to generate a separate viewer window simply because it is a better way to view information that you are particularly interested in. For instance, if it is an object, Best View in the viewer window is itself an explorer view, so you can see that object by itself without the other contents of the main explorer — and then you might generate yet another separate viewer window focusing even more tightly. If a value is a native datatype, the display in the viewer window may be easier to read (for example, in the case of a long string). The illustration below shows a cascade of viewer windows. From the Finder explorer, we separate off the selection in its own window; from that window, we separate off item 1 of selection in its own window; from that window, we separate off creation date of item 1 of selection in its own window.

Another reason for opening a separate viewer window is that sometimes it shows the information better than the original explorer view does. For example, in the Finder’s explorer, the selection object is a list. You can expand this list’s entry to see its items, as shown in the illustration below:

…but if you expand one of those items in the explorer, you do not see the elements and properties of that object. Instead, you see a lot of error messages. The reason is that we’re asking the Finder for things like bounds of item 1 of selection, and the Finder chokes on this sort of expression. The solution is to double-click the selection line, opening a separate viewer window. Here, the items and their elements and properties are fully displayed. The reason is that we’ve already fetched the selection, so in this window we’re asking the Finder for bounds of item 1 of (get selection), which works.

In general, don’t be perturbed by error messages in an explorer. These are marked in orange, with a stop-sign icon, as in the illustration below (CSS palette, from BBEdit’s explorer), and they indicate that Script Debugger asked for an element or property and the application responded, in good order, with a runtime error.

An error message, or a missing value result, are valid responses from the application. An «empty» value (as in container in the above illustration) is supplied by Script Debugger to indicate that the application has failed to return any value at all. This is useful information because if you assign such a non-value to a variable in a script, that variable will be undefined (try telling BBEdit to set x to container and then displaying x and you’ll see what this means).