Versions Compared

Old Version 6

changes.mady.by.user Mark Juras

Saved on

compared with

New Version 7

changes.mady.by.user Mark Juras

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

The approach outlined in this document is deprecated.  SharedFile is now implemented using a gmUtility as described here.]

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.


Code Block
languagenone
themeEclipse
linenumberstrue
    <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).


Code Block
languagenone
themeEclipse
linenumberstrue
 
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


Code Block
languagenone
themeEclipse
linenumberstrue
 <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.
Panel
bgColorCCFFFF
titleTable of Contents

Table of Contents