Skip to content

Parsing Source Code

Any source file can be considered to be autonomous or non-autonomous.

Autonomous Files

An autonomous file is a file where all of its class dependencies (required super classes and mixins) are satisfied by the file or by one of the files it uses. From a development point of view, an autonomous file is the most flexible type of file. You can drop this file into any project or use it within any other file, and you are sure that all of the files required to allow this file to compile have been brought along. From the Studio's point of view, an autonomous file allows it to most fully understand and therefore most fully model the classes and objects within the file. All of the objects, classes, super classes, mixins, and their interfaces are known to the Studio.

Non-Autonomous Files

A non-autonomous file is a file where not all of the class dependencies are satisfied by the file or the files it uses. A non-autonomous file cannot be compiled stand-alone. However, when used within a project, a non-autonomous file can be properly compiled. This occurs because the files and classes that the non-autonomous files depend upon are provided by the other files used within the project. The Studio cannot fully model a non-autonomous file when it is considered as a stand-alone file. Classes and interfaces may exist in other files, and the Studio has no way of knowing where those classes are.

What is needed is some way to tell the Studio that a non-autonomous file is part of a larger project. The Studio provides this capability in a straightforward manner. If your non-autonomous file is a member of the current project (i.e., it will get used and compiled when the current project is compiled), the Studio will use all of the files available in the current project to help satisfy any missing dependencies. You might think of this as a shortcut. If the file is available to the current project, it is also available to a non-autonomous file, provided that the file is a member of the current project.

Modeling Files

The Studio applies the following rules when attempting to model a file. By "model," we refer to the actions taken by the Studio's designer-view, property panel view, and DDO Explorer view.

  1. If a file is autonomous, it can be modeled. This is the ideal.
  2. If a file is non-autonomous and part of the current project, it can be modeled.
  3. If a file is non-autonomous and not part of the current project, it cannot be modeled.

While it is obviously best to always create autonomous files, it is not required. If you develop with the mindset of always working on a current project and you ensure that the files you are modeling are part of that project, then points #1 and #2 above provide essentially the same modeling capabilities. The only modeling drawback with non-autonomous files is that you cannot model them outside of the context of their current project.

It is possible that a non-autonomous file that is part of a project (point #2 above) could still have missing classes. When that happens, this is an error—the project will not compile. The Studio will allow file modeling, but the modeling may not be accurate because the data provided to the Studio about the classes is not complete. When this occurs, you will want to fix the error.

Even if a file cannot be modeled by the Designer View, DDO Explorer View, or the Properties Panel, it can still be used within the Studio by the Code Editor and Code Explorer views. Code-sense in the editor is also available for these files. The code-sense may not be as thorough because super classes, mixin classes, and their interfaces may not be available.

When working with non-autonomous files, it is best to work within the current project they belong to.

Foreign Files

A file may not even be part of the current workspace. This occurs if a file is not found within the workspace's source path (appsrc, ddsrc, etc.) directories or sub-directories. These are referred to as foreign files. If a file is foreign, it cannot be modeled. Even code-sense will not be available as it would be providing information from the wrong workspace. The Code Editor and Code Explorer Views can still be used.

Files With Structural Errors

There is another type of error that will prevent modeling of files. If a file is not structured properly, Designer, DDO, and Property modeling are disabled until the file is corrected. An example of a structural error would be a class nested within a class, a class without an end_class, or an object without an end_object. When these types of errors occur, the entire structure of a file is suspect. A single extra object command or a missing end_object command can completely alter the structure of your objects. Attempting to model these would only result in misleading information (i.e., things might look right but be very wrong). These kinds of errors must be corrected within the code editor.

Making Autonomous Files

Because autonomous files are more flexible, it is desirable to make autonomous files whenever possible. It is also desirable to convert old non-autonomous files into autonomous files. This is done by identifying the missing classes and providing the required use statements where those missing classes are defined. The Studio makes this easy to do.

A file can only be autonomous if all of the files it uses are also autonomous. Therefore, before you can make any file autonomous, you must first ensure that all the files it uses are autonomous. The Problem Resolution window provides a list of all missing classes (super classes and mixins) for the current file and for all of the files used by the file.

Remember that non-autonomous files are not errors. They are only errors if the classes referenced are never defined anywhere within a project.

Configuring the Studio Parser

The Studio Parser can be configured with respect to how it should treat #IFDEF source code blocks. By default, the Studio parses all code on both sides of the #IFDEF, and it can be configured to parse only the true block or the false block. In most cases, the default configuration will be adequate. It means that the Studio will parse and collect information about both sides of the specified #IFDEF block, which gives the Studio more information about your workspace.

However, in some cases, parsing both sides of the #IFDEF block can cause conflicting information, which may lead to metadata errors. For example, both sides might define a class with the same name, which would confuse the Studio. In that case, you can configure the workspace to treat the specified symbol as evaluating to true/false, which will instruct the Studio to parse only one side of the #IFDEF block. In most cases, #IFDEF blocks cause no metadata conflicts, and the Studio can safely parse both sides, simply collecting as much information as possible.

To configure how the workspace should treat specific #IFDEF symbols, open the Configure Workspace Properties dialog, accessed from the Tools menu, and select the Conditionals tab. You can specify each #IFDEF symbol, e.g., USE$VPE, and whether the Studio should parse the true/false block.

The Studio also has a built-in #IFDEF rule, IS$WINDOWS, which evaluates to true and causes the Studio to parse the true block and ignore the false block.

See Also