Suppose you have the following portfolio in the Solaris(tm) computing environment:
In this portfolio, you create the following two projects:
The WorkShop stores the projects in the example.psf portfolio file as follows:
Suppose you are working on Windows NT or Windows 95 and you have the following portfolio:
Into this portfolio, you import the following projects:
The first project is on the same drive as the portfolio. The WorkShop stores the project in the example.psf file as bubbles\bubbles.prj.
The second project is on a different drive than the portfolio. The WorkShop can't make this path relative. The WorkShop stores the project in the example.psf file as e:\examples\blink\blink.prj.
Now suppose a user on the Internet accesses c:\examples\example.psf and copies the Bubbles project to his or her current portfolio, c:\demos\new\newdemos.psf. The WorkShop puts the copy in c:\demos\new\bubbles\bubbles.prj.
If the user copies the Blink project into his or her current portfolio, the WorkShop places it in e:\examples\blink\blink.prj. If this location does not exist, the copy/paste operation fails.
Some project information requires that you enter a path name. For example, the Build tab in the Project Editor contains an attribute in which you specify the path to the root directory of the class hierarchy. The WorkShop creates project attributes that require a path name relative to the project (.prj) file.
If you specify a path that cannot be made relative to the project, then other users may not be able to access or use the project. For example, suppose you are working on Windows NT or Windows 95 and you enter e:\myclasses as the root directory of the class hierarchy. If other users copy your project, the "root directory of class hierarchy" works only if they have an e: drive with a myclasses directory.