Developers

Omnis Technical Note TNNO0013

The Notational approach to using FileOps

For Omnis Studio 3.02
By Tom Hume
Raining Data Technical Support

This technical note describes the differences between the two approaches to FileOps in Studio and the required changes needed for the upgrade to Studio 3.02.


FileOps explanation and differences

Omnis Studio provides the means to manipulate files in many ways with the 4GL command set available via the FileOps External Component (Xfileops.dll). More recently, in tandem with this, it is now possible to use the FileOps External Object for enhanced functionality and ease of use. The latter method will be, in effect, replacing the old way of achieving this functionality in Studio 3.02. This technical note is intended to outline the benefits of the External Object approach and ease the transition from the old 4GL commands to the new notation.

There are two distinct sets of FileOps methods; dynamic and static. The dynamic methods are available from the Interface manager when you create an instance of a FileOps object variable. These usually pertain to a particular file i.e. the file that you are working with. To create this object you would need an object variable with a subtype of FileOps. A typical code example could be using the $setfilesize dynamic method:

Do objvar1.$setfilesize([ifilesize])

Where objvar1 is the object variable of subtype FileOps, and ifilesize is a parameter of type Long integer. The static methods are available from the catalogue. External objects can contain static methods that you can call without the need to instantiate the object. These are the methods that would need to be prefixed with 'FileOps'. For example:

Do FileOps.$deletefile(filepath) returns lvError

This deletes the file specified with filepath and returns an error code into lvError if there are any problems and zero if there are not. A full list of error codes is available in the Omnis reference manual.


Conversion

In order to upgrade current applications to Omnis Studio 3.02, the old style 4GL FileOps commands would need to be replaced. An example of converting the old commands to the new notational approach follows. The external command to close a file is:

Close file (refnum) returns lvError

This command closes the file referred to by the file reference number or DOS file handle specified in refnum. Using the $closefile dynamic method of the FileOps external object the required code is:

Do objvar1.$close()

Another example of converting old code to take advantage of the new approach could be highlighted with copy file. The old approach would have been:

Copy file (from-path[,to-path]) returns lvError

Using the new functionality, this is achieved with the following code:

Do FileOps.$copyfile(from-path[,to-path]) returns lvError

The following tables describe the old way of coding FileOps functionality versus the new way.


Static methods:

Dynamic methods:

a.) The static methods - The catalogue>>Functions>>FileOps
b.) The dynamic methods - available from the Interface Manager when the object var is instantiated

Although not recommended, it is possible that backward compatibility could be retained in terms of FileOps. In other words, applications developed prior to Studio 3.02 could still be upgraded to take advantage of all the other benefits available in 3.02 and still use the old style FileOps approach with external commands. This could be achieved by copying the old external Xfileops.dll from the Studio 3.0 tree and placing it in the External folder of the Studio 3.02 tree. However, there are important considerations that one should bear in mind. The old FileOps commands are not supported on Mac OS X so there could be inconsistencies when deploying cross-platform. The commands will essentially be obsolete and the added functionality of the new way would not be available so code would also be inconsistent with regards to FileOps.