Database

Default database to be loaded at startup (if option is checked).

This one is normally the latest one loaded before closing the application.

 

Name of the repository to be loaded by default at application startup (if option is checked).

 

When set to YES, repository panel will be displayed at startup (on the right).

 

When this option is set to YES, auto-saving of the database will automatically occur periodically as defined by the user from the selection list:

 

When this option is set to One File, vsTASKER will embed the database under one main file (default)

When the option is set to Multiple Files, vsTASKER will create one file per Environment category (Logic, Knowledge, Models...) This will allow database sharing.

 

When checked, the database validation tool is called before generating the code. It is checked by default.

 

This option force the generation of the setters with default values in the setDefault() function generated for each vsTASKER objects supporting a Dyn-UI. It has become optional since version 6.1 as since, it is possible (and recommended) to specify default values directly into the header file for embedded interfaces INTF[], using DEF[] keyword (see here).

Initially, embedded Data-Model or Components (like LinearCtrl) could not be initialized with default values other way than from the code.

Activating this option for version 6.1 and above is useless and should remain off.

 

When disabled, all comments (system and design) will be removed from the generated code. This can produce smaller code or difficult to understand code when this one must be shipped with a locked database (for recompilation). Default is ON

 

If this option is checked, every time database is written, the previous one is backup with a sequential number (db_name.bak223).

If unchecked, the old database is erased.

 

Option is checked by default even if this can lead to having many files in the database. Reverting to a previous version is easy as the highest number represents the latest version of the database.

 

When this option is checked, database (design) is saved every time the code is generated.

The runtime database is always saved at code generation as this one will be loaded by the simulation Engine.

 

When checked, vsTASKER will try to connect to the Internet at each application startup to check if a new release or update is available.

This option is off by default as it slows down the launch when Internet is not available, slow or behind a proxy.

When enabled, the generated code will contain all the necessarily blocks to retrieve the user changes in the remote files and retrofit them. Default is ON.

 

 

When Code Updater is enabled, whenever a change has been detected in the code, user can accept or reject the update. Disabling this option will authorise the updater to retrofit all changes silently. Default is ON (user must accept every change)

 

 

When checked, each time the GUI is focused (or database loaded), the modified time stamp of the generated code files is compared with the database one. If one of the files has been modified, the updater will trigger.