Project Properties

Parent Previous Next

Project Properties.

Each SCRAMBLECODE project uses a project file to store all the properties as a single setup. This page describes all the visible properties, but the project file also contains information about the included source files, groups, the tree structure presented by the Project Explorer and  much more. The project file is stored in an XML format but should not be edited in a text editor, because some properties (i.e. the tree structure) are not easily modified.



The overall and most general properties of a project are these:

Property

Description

Name

This is the name of the project. It may appear:

  • In the title bar of the IDE window when a project is open.
  • As the top node in the tree structure presented in the Project Explorer.
  • In the list of recent projects - stored in the projects.xml file as described in Options.
  • As one of the projects currently imported in the debugger as a Compilation Unit File.

Hint

This text will be presented as a tool tip for the project node in the Project Explorer. If no text is present, the path of the file is shown instead.

File

This is the path of the project file, which stores all the properties described on this page.


More specialized properties are grouped and presented on different tab-pages as described next.


Compile + Build.

Property

Description

Target

In order to compile and generate bytecode you must select a target - defining which VM DLL is intended to execute the generated bytecode. The default target is based on the Evaluation LicenseID.

Include Trace Information in Bytecode for Debug Analysis

A lot of trace information for debugging can be generated automatically by including extra assembler instructions into the generated bytecode (increasing the size significantly). The compiler can insert the necessary trace instructions for:

  • Trace Code: Enable this to be able to debug your source code.
  • Trace Assignments: Activate this feature to trace the assignment of values.


WARNING: Never include trace information in bytecode for release.

Copy Bytecode to Clipboard

If the generated bytecode is to be inserted into your host application, this property can make it simple to copy and paste the bytecode - defining how to format the bytecode and how to break it into multiple text lines of a certain maximum length.


Example:

- Format:

    "$(ByteCode)" +

- Line Length:

255

By using the formatting variable $ByteCode as a placeholder, this example will break the bytecode into substrings on multiple lines, where each substring is no longer than 255 characters, and where each is given a starting and trailing ", and each is indented with these spaces       at the front and is assigned a  + at the end of each generated line.


TIP: This property is very useful once the bytecode is tested and ready for deployment. However, during the development phase with repetitive testing and debugging, it is usually easier to use the next property to compile and save to CUF, and then load the bytecode for test execution using redirection as described here.

Save to Compilation Unit File (CUF)

This property is used to create Compilation Unit Files also known as CUF. These files are generated when compiling the source code into bytecode, and each project generates one file (specified by the CUF path) containing the project name, bytecode, time-stamp and target. The generated CUF may also include the source code, if the property Trace Code is enabled.


TIP: Compilation Unit Files are used by the debugger but they are also useful to make the repetitive process of doing compiling and test execution easier as previously mentioned.


Group Lines.

Property

Description

Include #Lines as Code

By enabling this property you can control the functionality of the Group Lines individually by enabling or disabling the properties #0, #1, ..., #9.


The memo box can store comments about what each group of lines is used for.


Test + Debug.

Property

Description

Test Execution


Debug and Trace Analysis


You can enable the possibility of having the project file store the path of the last setup file used for either testing or debugging.


This is useful in combination with the activity events enabled in Options to allow for having the respective forms perform an automatic load of the setup settings last used by this particular project.