Current Page: NeXtMidas Training Primitives Files in a Primitive A Note About Files
| Important Note: The past few slides have shown the most common ways of accessing frame-based and record-based data. NeXtMidas provides alternative methods that may be more appropriate to a given situation. `FILE COPY` treats all files as simple binary ones and uses byte-based read and write methods. It is possible to treat most frame-based data as record-based and record-based as frame-based. `LIST2` treats all data as record-based (listing is an inherently record-based activity). `NOOP` treats all data as frame-based (simplifies this primitive and improves copy speed). See the `DataFile` API for more examples of modifying/writing frame and record-based data.
Don't Make This Mistake:
Do not forget to close your input/output files in your primitive's `close` method, otherwise not all data may be written or your primitive may be holding on to resources that it no longer needs, causing a "resource/memory leak". Additionally, you should check if your file is null otherwise you may get a NullPointerException.
    public int close() {
      if (outfile!=null) {
        outfile.close();
      }
    }
Java Experts Take Note:
File offsets and sizes are of type `double`. There are two reasons for this: It allows bit indexing (fractional part indicates bit in byte) for frame-based data. It is consistent with the definition of Midas Blue files. (The definition of a Blue file pre-dates widespread support for 64-bit integers, and the only way to support file size larger than 2GB was to use a `double`.) Many new applications/primitives (like LIST2) that work with record-based data internally store row numbers as a `long` and cast it to `double` when reading/writing (this prevents the user from entering a fractional record number).