SharedFile Statement Summary
SharedFile is terminal, utility statement that can occur only in command scripts. It is used after a set of project files have been loaded with the
SourceCode attribute turned on. It scans the loaded form, class, and module files to see if any are loaded by more that one project. It then reports the summary counts and gives a detailed listing of each shared file and the projects that use it.
The
SharedFile statement has no attributes or substatements.
This utility is completely general and can be used for any multi-project application once the
BuildOrder has been established. A sample script using it looks as follows.
<gmBasic>
<Storage Action="Create" Identifier="Shared" />
<Select Target="..." Local=".." System=".." />
<Load project="project(1).vbp" SourceCode="On" />
<Load project="project(2).vbp" SourceCode="On" />
.....
<Load project="project(n).vbp" SourceCode="On" />
<Output Status="New" Filename="SharedFile.out" />
<SharedFile />
<Storage Action="Close" />
</gmBasic>
The projects must be loaded in build order. The
SharedFile command then produces a report that starts off as follows (counts will clearly vary).
There were 94 Shared Files in this group of projects: Modules = 55, Forms = 2 Classes = 37
The Module file [module.bas] is shared by 258 projects
(1) project(i).vbp
(2) project(j).vbp
......
and it then concludes with a set of
GlobalSettings registry commands that look as follows
<Registry type="SharedFile" Source="module1.bas" Target="project(i).vbp" />
<Registry type="SharedFile" Source="module2.bas" Target="project(k).vbp" />
<Registry type="SharedFile" Source="module3.bas" Target="project(k).vbp" />
.....
These SharedFiles are being used within other codes. They participate in the TypeInference algorithms and have their types inferred based on that other code. Once they are pulled out separately their types can no longer be changed by other codes. An IDF is needed to ensure this. The process goes as follows: First, the
GlobalSetting Registry command
SharedFile names the SharedFile as the Source and names that project to be used to establish the precise typing for the Shared File as the Target. Second, when the target project is processed it will produce the shared form of the file and it will also produce an IDF file for that code. Third, downstream projects, when their project files specify a SharedFile, would load the IDF not the actual file.
The convention used by the
ShareFile utility statement above names the first project in encounters using the shared file as the target process. Henceforth these projects will be referred to as the "Defining" project for the shared file. Projects that load a SharedFile, but are not the Defining project will be termed a "Using" project of the shared file. Since the projects were loaded in BuildOrder this will ensure that there are no first-order circular references introduced -- i.e., the defining projects will also precede the using projects for every shared file. However, given that cross-references between shared and non-shared code will be present it is impossible to say how complex the circular reference problem will be for client codes that have them.
Mark Juras