• EDevelopment environment (GitLab, Emacs etc) is automatically installed by Operator.
• GUI for creating/editing workspaces with just a few clicks.

• Environment variables are set up for your Emacs and other processes instead of globally. You can therefore run multiple Emacs instances, cmd-windows, work in different workspaces simultaneously and others.

• You can also set up your workspace to get core-files from a label of choice (beta-label, release-label etc) while still getting latest revision of other files.

• Integration with Build Central for ease of building, monitoring, and publishing code.
• Troubleshooter that solves common problems with the environment.
• Button for starting CET Designer directly, without needing to manually compile/build from emacs.

A regular workspace can be used with all features except "Continuous Build". You will want to use a regular workspace to develop and submit code.

A build workspace is used as a read-only workspace (with the exception that you can change version numbers), where you select a submitted changelist number and then build your extensions from that revision. The benefit of that is that you then know that the built extensions correspond to the code submitted at that changelist and does not contain any unsubmitted changes. A build workspace also allows better traceability when building extensions for release as compared to a regular workspace.

You can start different architecture versions of the CET Designer by switching between the 32-bit and 64-bit button.

Starts an instance of CET Designer from the selected workspace. It does this by starting a _cm-instance that executes the “robustStartDesigner”-method (in develop-mode).

Solves common problems that can occur with your environment by clearing the write folder. For example, a corrupted file that resides in the write folder could prevent CET Designer from booting up.

The File Paths dialog gives you shortcuts to essential file locations for your workspace, CET Designer and CET Developer.

Starts a cmd-window for the selected workspace. In the same way as for the “Launch Emacs”-command, it works by setting up workspace-specific environment-variables (CM_HOME etc) for the specific process. This eliminates the need for setting the global environment variables and allows working with different workspaces simultaneously as the different processes have different sets of environment variables. This launches it with Administrator rights which will allow you to access files that requires access permissions.

Launches a dialog in which you can search in all file formats (.cm, .rs, .cpp, .m etc). This is in addition to the existing TAG search which only operates with the .cm format. This is a brilliant way to get an overview of the locations in which a particular string is used, and so on.

Build Central is used for building extensions and monitoring submitted code by performing continuous builds.

Launches the Test Assistant dialog that allows you to view crash reports collected by the Test Assistant, and starts CET Designer in Test mode for the selected workspace. Test Assistant makes CET Designer run automatically, randomly navigating and using all kinds of features of the program until it crashes. It then restarts the program and continues until it crashes again and so on. 

You may, at times, find yourself wanting to add/remove code from paths that weren't checked during the initial process of creating a workspace. You can use the this to handle situations of this sort. When you are done making your changes, CET Developer will add/remove files to/from your workspace.

Clicking on the delete button removes the workspace from the server and from your local drive.

When a workspace is set to be offline, CET Developer will not perform any Perforce-commands on it. You can then move its folder safely to another location. When you want to use it again, you can move the folder back and set it online.