Generic Project Inspector

alpha version, October 2000

Some project and subproject types have inspectors of their own. Though, there are a few generic attributes of any project type; it is worth it to serve them by a generic project inspector, available for each project type which is not served by a more special one.

Currently, the generic project attributes are the UIDs 1-3, and the versioning information. In future there will be more, like the CVS support , or archivation.

Opening the inspector describes where the inspector is to be found;
in Inspector Panel all the controls are shown and described;
Command Line explains how to specify the application capabilities in a "ProjectBuilderless" XSdk.

Opening the inspector

Whenever the current project does not have a specific current project inspector, there is a menu item "Generic Project Inspector", automatically added to the "XSdk Tools" submenu of the main application "Tools" menu--it will be the first one in case there is no root project inspector, and the second in case there is one (like on the picture, where the root project is an application, ad thus the first menu item is the Application Inspector):

ApplicationInspectorOpening

Choose the "Generic Project Inspector" command to open the inspector panel for the curent project or subproject, whatever is selected in the ProjectBuilder just now.

Inspector Panel

The Generic Inspector panel shows and allows to edit the project UIDs and the project version:

GenericInspector

Like in all other XSdk panels, the Assistant icon in the right top corner opens an appropriate help page. The functions of the other controls are described below.

Versioning support

There are three values you can check or change, and two more for information only.

The version number, divided to the major and minor part, needs a little description. With libraries and frameworks you should comply to the convention that the major version number is incremented whenever there are changes which break the compatibility altogether, and the minor version is incremented when there are changes which prevent a backward compatibility, but maintain the upward compatibility (ie. the old software with the new library will work, whilst a new software with the old library will not).

You can use any versioning scheme for applications or executables.

Currently the convention is not enforced, but some support for automatical version checking with frameworks is planned, which would work best with the convention. Besides, whenever the minor version is incremented, the Inspector tries to locate a generated DEF file, and if succeeds, the file is copied to the main project folder as a FRZ file. When the major version is incremented, the FRZ file--if any--is removed. This half-baked support will be considerably improved in future.

The "beta" checkbox is more or less for your convenience: it allows to maintain the information whether the application is a beta or the final release, and allows you to change the behaviour accordingly (eg. making the beta to be limited until some date, or so).

Finally, the build number and the built date are set automatically whenever the project is built (currently only when it is built in the ProjectBuilder, but the future versions will reflect a command-line building as well).

The version and build numbers and the information of the beta stage are offered to all the source files when compiled in form of predefined macros: XSdkVMajor, XSdkVMinor, and XSdkVBuild are defined to their appropriate values, whilst XSdkVBeta is defined only if the project in in the beta release stage.

Unique IDs

All the three UIDs are always shown. Some of them, though, can be freely editable, and some not. The information which UIDs are editable is placed in the appropriate project type, along with the short prompt to be shown for the editable UIDs (like the "Application ID" on the previous picture, or the "Interface ID" and "Vendor ID" on the next one):

GenericInspector2

In case the UID is editable and should contain a Symbian-allocated UID, it has been automatically initialized using a free temporary UID when the project was made in the Assistant. The "Assign Final UID" button is enabled, and allows you to "reUID" the project from the temporary one to a final UID, useable for a public release. See also the UID management for information how the XSdk helps you to maintain the unique ID numbers in general.

If the UID need not contain a Symbian-allocated UID (like the vendor UID for a polymorphic interface DLL, where the UID2 is sufficient to distinguish different libraries, and the UID3 can contain any value), it has been initialized to some fixed value specified in the project type (quite often a zero), and can be edited, but the "Assign Final UID" button is naturally disabled.

The UIDs are shown as hexadecimal numbers in the C-like notation. You can enter new values either the same way (using both lower- and uppercase for the 'x' and the digits over 9), or in the assembler-like notation (hexadecimal number which must begin by a decimal digit and has a 'h' or 'H' suffix, ie. "0fbca972h"), or as plain decimal numbers.

If interested how the UID attributes are specified, you can check the project template description.

Command line

There is currently no command line tool to specify the application attributes; when using a "ProjectBuilderless" XSdk, you have to set the appropriate values manually in the PB.project file. See the Makefiles document for the general PB.project file format. The appropriate keys and values are: