You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Overview

Our platform can run multiple projects at the same time by simply changing the port. Users can run multiple instances of the same project using the Runtime and the Test mode, making it possible to develop and test without requiring to stop the production. 

On this page:


the Build Feature

The Build feature compiles all project's displays and scripts for final verification before deploying the project for production. Build provides complete verification of an application's scripts when preparing it for final production. However, this is not necessary during the development stage since all project modifications are automatically and transparently compiled in the background while a project is edited. 

The Build selection has two information tables:


Messages shows the current status of each script and display potential errors or warnings.

History shows the number of times you executed a whole build for this project.

The Build command does not need to be executed after a project is edited as it happens automatically in the background. The Build command only needs to be used as a final verification before a project is deployed or for when a build number is needed. 


Executing a Build is useful for achieving complete verification of an application's logic when an application is being prepared for final production, but it is not necessary during the development process. Any modifications you make on a project are automatically and transparently compiled in the background while you are editing. 


A project's configuration is saved in a file with the extension "tproj". Using the Publish procedure that is described in Run, Test, and Publish Projects <<<<.please check the page name and insert a link>>>>, you can create read-only versions of the project for runtime execution only. This version will have the extension ".trun".



Publishing Your Project

Click the Publish icon.

The Publish command creates a read-only protected version of a project that is suitable to be deployed in the field.

When the Publish command is executed, a new Project file (with extension ".trun") is created with the version number selected. The Published Projects (".trun" extensions) are similar to the current project (".tproj" extension) and can be opened only in read-only mode. This provides you with a safe backup version of published applications.


A project does not need to be published unless a read-only protected version of the file is warranted. Otherwise, the project file needs to be copied to the target computer. 


UseCount: Shows how many times each object is used inside the application, along with a reference to the object.

CrossReference: Shows where each object is used and shows a list of unused objects. You can double-click on a selected reference in order to jump to its location.



Build and Pack Projects

The platform constantly compiles the module you edit in the background and validates all scripts and displays. If you have not run a full build, the BuildStatus column reflects any warnings or errors found during the background compile process. 

If a row has a red X, double-click it to go to the source of the warning or error. Warnings are informational and do not stop the script from running. Errors prevent the specified script from running, but do not affect the whole application. Even if a script or display has a warning, it will still run. 

Periodically, you should run a full build:

  • When you have made many changes and you want a full validation and to recompile the whole project.
  • When you want to assign a build number to a version.
  • When you want to pack the database. When the build executes, the system creates a backup of the current project file. If you want to save the project as it was for the build, rename the backup file.
  • When you are getting ready to publish, that is, create the read-only runtime application.


To build the application:

  • Go to Run → Build → Messages.
  • If you want to pack the database, select Pack database after build to significantly reduce the project file size. The system creates a file with the backup extension, which is the database before the application is packed. You may want to pack the database every time you run a build.

  • If you want to save all displays, select Verify Symbols and save all Displays. Be sure to use this option if you have made changes to the symbol library. This option applies to all symbol library changes throughout the project.

  • Click Build.


When checked, a backup of the project that is connected with the build is automatically created. It is also possible to pack a project without building. To do this, click the Pack button.


Project Version Control

Tracking configuration changes

Our platform provides many ways to help you track the project configuration changes:

  • All configuration tables have the DateCreated and the DateModified information.
  • The Run → Build → History page shows all Build commands executed in that project. According to your user settings, you may be able to access a backup version of the project with the settings and values it had when that version was built.
  • The Info → Track → Tables page shows all configuration tables, lists the number of rows, and shows if the tables were changed.
  • The Info → Track → Changes shows all project objects that have been modified. In order to enable or disable this, you must be logged in as an Administrator. By default, object tracking is only enabled after you publish the project, but you can enable it anytime.

Publishing the Project

Publishing the project creates a read-only version of the project.

It is NOT necessary to publish the project to install it for production. If the project is expected to have continuous changes when in the field, it is easier to put the main project file (tproj) directly on the production computer. 

The main benefit of publishing is that the system creates a compact and read-only version of the project file. The created file has the same name of the project's and it has the publish version number along with the ".trun" extension. This allows the system to comply with regulated industries. 

The publish command is usually used in case you want to:

  • Deploy a read-only version of the project. For instance, to be in compliance with certified and regulated environments.

  • Use the automatic version numbering system. The result of publishing is a ".teng" file that also contains a major (1.0) or minor (0.1) version number as part of the file name. In addition, Info → Track helps you manage the files published to the field, including which project build they are.
  • Have a smaller footprint and faster loading of the project. For instance, on machines, OEM, and embedded systems. The ".trun" file can be up to 5 to 10 times smaller than the ".tproj" file.
  • Protect the project from modification.


The ".trun" file is always read-only, but you can optionally hide the project configuration from the end-user as well. This is an independent option defined in the Security System. If you do not want end-users to see the project configuration, remove the permission of the GUEST user and other users to edit the project before publishing it. 


To publish the project:

  • Go to Run → Build → Messages.
  • Select the desired build settings and Click Build.
  • Go to Run → Publish. The Current Project Settings fields show the read-only status of the project.
  • Select the Publish Settings you want.
  • Click Publish.



In this section...

The root page @parent could not be found in space v10.

  • No labels