The DataFlex Studio operates within a workspace. A workspace defines the areas where your source files reside. The workspace is the area where you build your projects. Projects are built by assembling components into a single file. The components will use classes that are known to the workspace. These classes can be defined within the workspace, within libraries used by the workspace, and within the System Library.
A project is the code that you compile and run. A project consists of a file (usually an .src file) that uses other components (component files, class files, Data Dictionary files, etc.) to create an executable program. A project can be large (e.g. MyBigApplication.src), containing all of the components and classes within your workspace, or it can be small (e.g. MyTest.src) consisting of a few components that you wish to test.
You can create as few or as many projects within a workspace as you wish. Projects must be registered within a workspace. This is really just a simple process of adding a file to a list that Studio maintains. Projects can easily be added or removed from this list.
The Studio is current project oriented. You are expected to select a current project and then work within this project. When you tell the Studio to compile, debug or run, it will always operate on the current project. When the Studio provides you with code-sense (interface information) it provides it from the current project’s perspective.
Selecting a current project is a simple process.
The workspace paths are the logical directory areas used to define your workspace.
AppSrc – this contains DataFlex source
Bitmaps – this contains images used within your projects
DDSrc – this contains Data Dictionary source
Data – this contains your data and data-binding information
Help - this contains help files for your projects (if applicable)
IDESrc - this contains Studio configuration files for the workspace
Programs – this contains your compiled projects (programs)
This is the path that contains:
Custom Classes - classes used by the workspace
Components – objects used by projects (views, reports, etc.)
Projects – These the files you compile and run
Class “Config” definitions – A special directory that contains information about the classes available in your workspace
Any source path may contain subdirectory paths. This provides an effective and recommended mechanism for organizing your files.
All subdirectories defined within a source path are considered to be part of the workspace.
Files in these workspace subdirectories must be referenced relative to their location of a main source path. Most often that main source path will be your AppSrc directory.
For example, assume you have the file AccountsEntry.vw located in the following directory structure.
This file is accessed relative to the main source path, AppSrc, and is therefore referenced as follows:
The file will be located relative to your main source paths. In the above example, it will find the file under the AppSrc path (“C:\DataFlex Projects\Order Entry\AppSrc\” + “AccountsPayable\Views\AcountsEntry.vw”).
Note that your use statement must include the entire relative path. The following statement would not find the same file:
Use AccountsEntry.vw // this will not find the same file
In the above example, the file would have to be located directly under a main source path (e.g. …\Appsrc\AccountsEntry.vw).
Subdirectories will be used most often under the AppSrc path. However, subdirectories may be located under and of the main workspace source paths (e.g. AppSrc, DDSrc) and all library source paths. All paths will be searched until the file is found. The path defined as AppSrc is always searched first.
The AppSrc path definition may consist of multiple paths. The first path, referred to as the Primary AppSrc Path, is the most important path.
Most often, you will only have a single AppSrc path. Additional paths can be defined more effectively as Libraries or as sub-directories within an AppSrc path.
The config directory must be located under the primary AppSrc path and must be named “config”. It contains information about your workspace’s class configuration. This includes:
The Class List - A class list is maintained that contains a list of all classes that should be displayed in the Workspace’s class palette
Object Preference Files – When an object is created by dragging and dropping a class from your class palette, a template file is read to determine what kind of custom code should be added to this object. This optional template file name consists of the class name with an extension “.DFO” and must reside in the config directory (e.g. appsrc\config\cMyButton.dfo).
Component Template File – When a new component is created, a template is used to create the new file.
Workspaces should not physically reside inside any other workspace or library workspace.
A Library is a group of classes (files) that are defined in a way that they can be used by multiple workspaces. A Workspace may reference any number of libraries. When a library reference is added to a workspace, the library files paths are added to the workspace’s makepath.
Libraries are themselves just workspaces. Libraries are created and maintained within that library’s workspace. Although libraries are complete workspaces, only their classes are used within other workspaces.
A library has its own AppSrc\config folder and will containing all of the required configuration information such as a class list and object preference files.
A library may reference other libraries. When a library defines classes, it will define those classes based on the super-classes that are already defined. Those will be classes defined in the library, classes defined in a library being referenced by the library, or classes defined in the System Class Library.
Libraries should not physically reside inside any other workspace or library workspace.
The system class library consists of the packages and classes installed as part of a Standard DataFlex installation. The files in the System Class Library are read-only and should never be changed by the developer.
All workspaces and all libraries always have access to the System Class library. They do not need to be explicitly added as a library.
When a project is compiled, a makepath is assembled. This makepath consists of a list of all paths required by the compiler to find the files needed to perform the compilation. This makepath is assembled dynamically by the compiler as follows:
All AppSrc paths in the Workspace
All AppSrc paths of all libraries used by the workspace
Other workspace paths - DDSrc, Bitmaps, etc.
The System Makepath – System Class Library (Pkg), Lib, etc.
The workspace paths are defined by the developer when they create or modify the workspace. The library paths are determined by which libraries a developer included in a workspace and by the workspace structure of those libraries. The System Makepath is system maintained and should never be changed by the developer.
A workspace is defined by an .SWS file that will be found in the root directory of a workspace (e.g. projects\order entry\order entry.sws). You may open a workspace by finding this file and double clicking on it. When you do this a new instance of the Studio will be loaded for that workspace. You may also select a workspace from within the Studio by either selecting a workspace from a most recently used list, or by navigating to a new .SWS file and selecting it. New workspaces may be created by selecting a “New Workspace” option.
Multiple instances of the Studio may be run as long as the each instance of the Studio is working in a different workspace.
Each Workspace maintains its own class list. This class list is displayed by the class palette. The classes in this list consist of classes defined within the workspace, classes defined within libraries and classes defined in the system class list.
The class list in any workspace contains a list of all of these classes. This list can be customized at the workspace level. This is all handled by selecting context menu options from the class palette. The following customizations are allowed:
New classes may be added
Classes may be removed
Classes may be moved anywhere in the list
New groups may be created to organize the classes
Copies of class entries may be created
All System classes can be hidden
When a library is added or removed from a workspace, the class list will be refreshed with this change. Once the change is made, you can reorganize the list any way you like. If a library changes (classes are added or removed from the library class list), a workspace using that class will get refreshed with that changes the next time that workspace is entered. Therefore, changes in libraries are always reflected in all workspaces using the library. The same rules apply to the system classes. Anytime the system classes change (i.e., a revision update) those changes will be reflected in the workspaces.
An existing class can be added to the class palette by loading the file containing the class and selecting Add Class to Palette from the class palette context menu. The class will get added with all of the required information.
New classes can be created and added to the class palette by selecting various options in the Create New Dialog’s Class tab page.
You do not need to add a class to the class list to be able to use it. Any class that can be modeled by the Studio will be modeled by the Studio. Adding a class to the class list simply adds it to the class palette, allowing you drag and drop the class into a designer view.
Libraries are added and removed from a workspace by selecting the Add/Remove Libraries context menu option from the class palette. When you add a library you will select the library by selecting the library’s workspace. You do this by finding and selection the Library’s .SWS file.
When you add a library, the Studio will allow you to add the library path as a relative or absolute path. Whenever possible, you should select the relative path option. The Studio will determine how to this path should be defined.
It should be your goal to organize your workspaces and libraries in a way that offers maximum ease of use, flexibility and portability. This is best accomplished by:
Use relative paths for all of your paths
Arrange your workspaces and libraries so that they have a common root. This makes it easy to support relative paths, makes it easy to check in and check out entire source areas, and makes it easy to copy development areas to other computers.
Use sub-directories under to AppSrc path to organize your files
Avoid the use non-primary AppSrc paths – use Libraries (2) and sub-directories (3) instead.
Do not change the system make path. If you want to add system-wide directories, use libraries
Below are two different examples of workspace / library paths that would work well. This first sample simply places all workspaces and libraries under the same path:
This sample places libraries and workspaces in separate branches, still under the same root
Studio Workspace Configuration Files