In order to be able to change an object's settings from "outside" the WPS, the WPS supports the concept of object setup strings.

A WPS setup string is a sequence of keyword=value pairs, each separated with a semicolon. The keywords that are understood by an object depend on its WPS class.

Since the WPS classes are organized in a hierarchical tree and inherit from each other, an object will not only understand the setup strings of its own class, but also those of all its parent classes. For example, a folder will not only understand WPFolder keywords, but also the generic WPObject keywords (which are understood by all objects).

There are many, many different object strings for the various WPS classes. Some of them are listed in the &xwp; User Guide.

Any application can invoke a setup string on an object to change its settings since OS/2 provides an API for this. But even REXX scripts can do this with the SysSetObjectData function from the RexxUtils DLL. A setup string can also be specified when an object is initially created (either from an application or REXX). This is very frequently used with installation programs and REXX scripts that create program objects for an application.

Note: As opposed to a popular misconception, when a setup string is invoked on an object, the string itself is not stored anywhere. Instead, the string is parsed by the object's WPS class, translated into the object's binary data, and then discarded.

As a result, in order to be able to retrieve setup strings again for the display on the "Object" page in an object's properties notebook, &xwp; has to evaluate an object's binary data and take a best guess at what the setup string would be that would create that binary setting. Some of the object data is completely undocumented, and unless there is a documented way to find out what the binary object data means, &xwp; will not be able to create a setup string from it.