12.10 Files used by UDO language and their location
In this section we shall summarise general principles for locating the various files used in the UDO language, and explain how the UDO interpreter searches for these files.
*.udo files read from QW-Editor
When we want to invoke a new UDO object from QW-Editor via the UDO Library, the content of the recently used object library appears in the dialogue. We can change the directory and pick up the desired *.udo file from any location.
When we want to modify an existing object and double-click it on the list in Select Object dialogue, the name of the *.udo file describing this object is taken from the project. In typical operation of the software, full paths to all the used *.udo files are recorded in the *.pro file, and hence we can be sure that the correct *.udo file will be loaded.
The only case of object modification which is not “typical” occurs if we have previously changed the recorded path to *.udo by text-editing the *.pro. Then the search for the *.udo file follows the same rules as in the case of *.udo called by CALL command from UDO scripts, as explained below.
*.udo files called by CALL command from UDO scripts
Let us first establish the meaning of “name” versus “short name”, "short name with dir" and “full name”. We can consider three basic possibilities of specifying file “name”:
a) my_udo.udo
b) c:\dir_1\dir_2\my_udo.udo
c) dir_k\dir_l\my_udo.udo
In all these cases, the “short name” is the same: my_udo.udo. Thus in case a) “name” is also “short name”.
“Name” in case b) is also “full name”.
"short name with dir" is in case b) dir_2\my_udo.udo and in case c) dir_l\my_udo.udo
In general, “name” may include any number of directories up from the file location, and thus may be anything between “short name” and “full name”. "short name with dir" includes one parent directory name (if “name” contains it).
As we will see, the result of CALL command depends on how the “name” has been specified. The interpreter tries to locate the file of given “name” in the following sequence of steps:
1. projectdirectory + name
2. given name (in practice, works if full name is given)
3. projectdirectory + short name
4. in consecutive directories set by the user as UDO Paths + name
5. in consecutive directories set by the user as UDO Paths + short name
6. in consecutive directories set by the user as UDO Paths + short name with dir
7. in elib directory + name
8. in elib directory + short name with dir
If all eight steps are unsuccessful, it terminates with an error message.
*.png or *.bmp files substituted for bitmap variable in the header of the UDO program
When considering a particular *.udo file, the interpreter tries to locate its bitmap file of given “name” in the following sequence of steps:
1. given name (in practice, works if full name is given)
2. *.udodirectory + name
3. in consecutive directories set by the user as UDO Paths + name
4. in elib\bitmaps directory + name
If all four steps are unsuccessful, it terminates with a warning message listing explicitly all paths that have been tried.
*.txt and other files opened by OPENF command (and read from by READF, READS)
The interpreter tries:
1. project directory + name
2. elibdirectory + name
3. given name (in practice, works if full name is given)
If unsuccessful, it terminates with an error message.
udodebug.txt file used by WRITEF and WRITES commands
The interpreter tries project directory + name. If unsuccessful, it terminates with an error message.
*.iop files used by GETIOPAR command
The interpreter tries:
1. projectdirectory + name
2. given name (in practice, works if full name is given)
If unsuccessful, it terminates with a warning message.
Go to next Optimising with UDO chapter.
Back to Syntax of the User Defined Object (UDO) language chapter.