The Lynx Exploration Archive Object

Version: 3.1

LEA Object Wizard version 2.3

• Introduction
• LEA Object Implementation
• The LEA Object Wizard
• Formats
• Attributes
• Script Files
• Using Dynamic Link Libraries
• Implementing LEA Objects as COM Servers
• Base Object Attributes
• Key Attributes
• Locale Independence
• Initialisation Errors
• File Errors

Back to:

• Main Index
• LEA Setup and System Files Index
• Data Cataloguing Index

Introduction

Lynx Exploration Archivist applications are able to access, catalogue and manipulate many different types of data file via the concept of a Lynx Exploration Archive Object. Lynx Exploration Archive Objects are designed as a framework to classify and access data by useage rather than by file format. For an end-user, the physical file format of exploration data should not be relevant: the information contained is important. LEA Objects enable applications to access the varous file-types encountered in exploration data archives (including seismic, well, location, raster, document and other spcialised formats) in a consistent and uniform manner.

The framework is designed to be customisable by users, so that additional formats and attributes can be added to existing LEA Object types, and new user-defined LEA Object types added which extend the functionality of Lynx Exploration Archivist applications.
The LEA Object Wizard can be used to edit existing LEA Object types, and add new types, with user-defined formats and attributes.

A file format is a definition of the layout of the binary information in a file. A proper file format is independent of the computer system on which the file is stored. In other words, the format definition should specify the byte order of integer and floating point types, the delimiters used in text files etc - in fact a complete definition at the bit level.
The LEA Object framework is designed to allow users to redefine the method used to recognise a particular file format used by an LEA Object type, or to add new formats to an LEA Object type, using local COM servers, script files or dynamic link libraries (see LEA Object Implementation below).

Every LEA Object type has a set of attributes. An attribute is one of the items of data present in the conceptual definition of a particular LEA Object type. For example the attribute "number of traces" is an attribute shared by all seismic files. This does not mean, of course that an actual seismic format implementation will necessarily define a place to put this attribute.
As with formats, the mechanisms used to read attribute values can be redefined, and extra attributes can be added to existing LEA Object types by defining their characteristics and access methods in script files or DLLs (see LEA Object Implementation below).

LEA Object Implementation

All LEA Objects are accessed through the same interface, which is provided by the ILEAObject interface in the LEA system file LEAOBCOM.DLL. This provides for

• Format recognition
• Attribute access

Each LEA Object type is defined in its own INI file. This INI file describes the file formats which each LEA object can recognise, and the attributes to read, display, and (in some cases) edit. The format-recognition and attribute access for these types is implemented in one of two ways:

• COM server DLLs - each standard LEA Object type has its own help file.
  The standard LEA Object types are as follows:
  • Base File
  • Documents
  • E-Mails
  • Maps and Location Records
  • Raster images
  • Seismic data
  • Wireline Log data

  Standard LEA Object types may contain mechanisms to read and write data as well as attribute values, however, data input/output is not part of the LEA Object defintion. Additional LEA Object types can be defined by creating a COM server that implemets the LEA Object interfaces required. See Implementing LEA Objects as COM Servers below

• Script files and DLLs- these allow users to customise and redefine LEA Objects on a per-format or per-attribute basis.
  • Script files allow users to recognise formats and read attribute values by reading and translating the values of bytes at specified offsets within a file. This method is not very flexible, but can be easy to implement for strictly-defined file formats.
  • Dynamic Link Libraries allow users to specify DLL functions for format recognition and attribute access. This method allows more complex format recognition routines to be used, or more loosely-defined file formats to be handled.

The LEA Object Wizard

The LEA Object Wizard can be used to edit existing and create new LEA Object types.

On startup, the wizard reads the LEAOBJ.INI file, and loads a list of the current LEA Object types from the [COM_CLASSES] section of this file.

The wizard has the following menu commands:

• File
  • Add Object
    This option can be used to add previously created LEA Object types to the list of LEA Objects stored in the LEAOBJ.INI file. Once an Object-type has been added to this list (stored in the [COM_CLASSES] section of LEAOBJ.INI) the Object can be opened and edited (see File-Open below) and used in other LEA applications such as Dougal and Florence.
    A file selection dialogue is displayed. Select the INI file that describes the LEA Object, to add this object to the list of LEA Object types.
  • Remove Object
    This option can be used to remove an LEA Object type from the list of LEA Objects stored in the LEAOBJ.INI file.
    Select the Object type to remove it from the list displayed. The INI file describing the LEA Object will not be deleted, but the reference to it in the [COM_CLASSES] section of LEAOBJ.INI will be removed, so that the Object type cannot be used in other LEA applications.
  • New Object  
    Create a new LEA Object type.
    To create a valid LEA Object, you must provide a description (see Object Description, below) and define at least one format (see Format Defintion tab page, below).
  • Open Object  
    Open an existing LEA Object for editing.
  • Save Object  
    Save the current LEA Object.
  • Save Object As
    Save the current LEA Object with a new file name. The new file name will be added to the list stored in the LEAOBJ.INI file. You should save the file into your local CUSTOM directory (the default folder for the save dialogue) unless you have a very good reason not to.
• Page
  The Page menu options display the four tabbed pages of the wizard's main window:
  • Object Description - see Object Description Page below.
  • Format Defintions - see Format Defintions Page below.
  • Attribute Definitions - see Attribute Defintions Page below.
  • Attribute Access - see Attribute Access Page below. This menu option and tab page is only activated when the current object has defined formats and attributes.
• Entry
  The task assigned to each item in the Entry menu depends on the visible tab page:
  • Add  
    Format Definition Page - Add a new format definition.
    Attribute Defintion Page - Add a new attribute definition.
  • Edit  
    Format Definition Page - Edit the defintion of the format currently highlighted in the list.
    Attribute Definition Page - Edit the definition of the attribute currently highlighted in the list.
    Attribute Access Page - Edit the access method for the attribute and format currently hightlighted in the grid.
  • Delete  
    Format Definition Page - Delete the currently highlighted format definition.
    Attribute Defintion Page - Delete the currently highlighted attribute definition.
  • Move Up  
    Format Definition Page and Attribute Defintion Page - Move the currently highlighted item up towards the top of the list.
  • Move Down  
    Format Definition Page and Attribute Defintion Page - Move the currently highlighted item down towards the bottom of the list.
  • Edit All Attributes  
    Attribute Access Page - Edit the access methods for all attributes for the currently highlighted format in the grid.
  • Edit All Formats  
    Attribute Access Page - Edit the access methods for all formats for the currently highlighted attribute in the grid
• Test
  • Create LEA Object  
    This option can be used to check if the LEA Object you have created or edited works correctly. Before using this option you must save the changes you have made (see File-Save Object and File-Save Object As).
    Select an LEA Object data file to open from the open file dialogue. If the file is opened correctly as an LEA Object of the type you specified, an LEA Object Attribute Display dialogue box will be displayed listing all the attributes and their values for this file. Check that these values are correct, and that the file is recognised as the correct format (the order of definitions in the format definition list can affect whether a format will ever be detected - see Format Defintion tab page, below).

Wizard Object Description tab page

This page (displayed above) allows you to edit the general properties of the LEA Object.

Object Name

This name is used in LEA catalogues for reconciling objects and their locations, and when selecting LEA Object types (for example in Dougal). The name should be short but descriptive. If no name is supplied, the name of the LEA Object's INI file is used by default.
This field is stored as the value of the name key in the [OBJECT_DESCRIPTION] section of the LEA Object INI file.

Object Description

This description is used when selecting LEA Object types (for example in Dougal), and also in the LEA Object Attribute Display dialogue and the LEA Object Attribute Editor.
This field is stored as the value of the description key in the [OBJECT_DESCRIPTION] section of the LEA Object INI file.

DLL File

The name of the DLL file that contains the COM server which implements the LEA Object. If the LEA Object is implemented by script definitions, the entry here will be the LEA Object system library LEAOBCOM.DLL. Click the Browse button to display a file selection dialogue. If the file name specified does not include a directory path, then the file will be searched for in the following directories:

1. The user's CUSTOM directory
2. The directory containing the wizard's executable
3. The LYNXSYS directory
4. The Windows SYSTEM32 and SYSTEM directories
5. The WINDOWS directory
6. Directories listed in the PATH environment variable

This field is stored as the value of the dll key in the [OBJECT_DESCRIPTION] section of the LEA Object INI file.

Class Name

The class name is used internally by the LEA application to create an instance of the LEA Object. This value is stored in the Windows registry, and is used to look up information about the object required by Windows in order to create it. The class name is referred to as the progid in Windows documentation. Select the correct value from the drop-down list, which is read from the DLL file specified above. If the LEA Object is implemented by script definitions, the entry here will be the base LEA Object LEAObCom.FileObject. See LEA Object Implementation above for more details.
This field is stored as the value of the com_class key in the [OBJECT_DESCRIPTION] section of the LEA Object INI file.

Default Viewer

This edit field can contain the default program to use to view objects of this type. Click the Browse button to display a file selection dialogue. If the file name specified does not include a directory path, then the file will be searched for in the standard system search path. You can also specify different viewers to be used for specific formats in the Format Definition below.
This field is stored as the value of the default viewer key in the [FORMAT_VIEWERS] section of the LEA Object INI file.

Help File

This edit field contains an optional name of a help file for the LEA Object. Click the Browse button to display a file selection dialogue. If the file name specified does not include a directory path, then the file will be searched for in the standard LEA help directory (usually a subdirectory of the LYNXSYS directory).
This field is stored as the value of the helpfile key in the [HELP] section of the LEA Object INI file.

Version Number

This is used to check compatibility at runtime between the LEA Object described in the INI file, and the version of the base LEA Object compiled into the executable file. You should not normally edit this field.
This field is stored as the value of the version key in the [LYNX] section of the LEA Object INI file.

LEA Object File Formats

Each LEA Object type can recognise a number of distinct file formats. A method of format recognition recognition must be defined, a (language-dependent) format name, and a list of common file extensions for this format.

Wizard Format Definitions tab page

This page displays all the formats defined for the current LEA Object.
Format definitions can be edited by double-clicking on the entry in the list (or selecting the Entry-Edit   menu option) and new format definitions can also be added (Entry-Add   menu option) - see format defintion parameters and options below.
Format defintions can also be removed from the list (Entry-Delete   menu option).
The order in which formats are checked can be changed by dragging items in the list, or by using the Entry-Move up   and Entry-Move down   menu options.

The order in which formats appear in the list is reflected in the order in which the LEA Object will check each format when attempting to recognise the format of a data file.
For instance, if you have two formats, where format 1 is recognised by the string lynx at the start of the file, and format 2 is recognised by the string lynx information systems at the start of the file, format 2 must appear in the list before format 1, otherwise format 2 will never be detected.

LEA Object Attributes

LEA Objects have a number of attributes defined. An attribute is one of the items of data present in the conceptual definition of a particular LEA Object type. For example the attribute "number of traces" is an attribute shared by all seismic files. This does not mean, of course that an actual seismic format implementation will necessarily define a place to put this attribute.

Attributes are read from a data file after the format of the file has been determined (using the format recognition method detailed above). If the attribute is present in the recognised format, then it is read from the file.
The built-in LEA Object types have a number of pre-defined attributes. These can be added to by users with the LEA Object Wizard.

Wizard Attribute Definitions tab page

This page displays all the attributes defined for the current LEA Object. Attribute definitions can be edited by double-clicking on the entry in the list (or selecting the Entry-Edit menu option). New attribute definitions can also be added (Entry-Add). The order in which attributes are displayed can be changed by dragging items in the list, or by using the Entry-Move up and Entry-Move down menu options.

This page displays all the attributes defined for the current LEA Object.
Attribute definitions can be edited by double-clicking on the entry in the list (or selecting the Entry-Edit   menu option) and new attributes can also be added (Entry-Add   menu option) - see attribute defintion parameters below.
Attributes can also be removed from the list (Entry-Delete   menu option).
The order in which attributes are displayed in the LEA Object Attribute Display dialogue and the Attribute Editor can be changed by dragging items in the list, or by using the Entry-Move up   and Entry-Move down   menu options.

Attribute Access

Once a file has been recognised as having a particular format, the LEA Object will read the values of all attributes using the mechanism defined for that format (see Format Definition - Attribute Access Method).

For standard LEA Objects with pre-defined formats and attributes, reading (and writing) these attributes is dealt with internally. For user-defined LEA Objects, or additional user-defined formats and attributes, you must also define a mechanism to read each attribute.

Wizard Attribute Access tab page

This page displays the a grid representing the method used to read each attribute for each format defined in the LEA Object. If the attribute access method specified in the format definition is not SCRIPT then the entry will be greyed out and cannot be edited here.

Note that the attributes and the formats are displayed in the grid in the order in which they appear in the defintion lists on the Format Definition tab page and the Attribute Definition tab page.

Edit an access method by double-clicking the entry in the grid (or using the Entry-Edit  menu option)
Edit all attributes for a format, or all (available) formats for an attribute by double clicking the row/column header (or using the Entry-Edit All Attributes  and Entry-Edit All Formats  menu options). These options can be useful if the access methods for all formats or all formats use the same DLL function, for example.
You can only successfully Edit All Formats if at least one of the format definitions has its attribute access method set to SCRIPT.

Script files

Script files can be used to add new file formats and attributes to LEA Object types.
See Format Recognition and Attribute Access above.

A script file is a text file in INI format with the entry

TYPE=SCRIPT

in the [LYNX] section, which defines the file as an LEA script file.

An LEA Object INI file may specify a script for format recognition or attribute access instead of using a COM library or DLL function. The named script file will be loaded from the first directory in which it is found from the list below:

1. User's CUSTOM directory (defined by networkpath or localpath in the LEA System Initialisation file LEASTART.INI - see LEA System Installation - System and data directories)
2. Application's current working directory
3. Directory containing application's executable file
4. LYNXSYS directory (defined as syspath in the LEA System Initialisation file LEASTART.INI - see LEA System Installation - System and data directories)

The script may specify either a value to read from a specified offset within the file, or a DLL function to call. The syntax of both these methods is discussed later.

Word Separator=,
Clause Separator=;
Quote Char="

n=SEARCHTYPE;INFO

Using Dynamic Link Libraries

A dynamic link library is a compiled collection of functions that can be accessed by Windows applications. DLLs can be written in many programming languages, such as Delphi, C and C++. You can specify custom functions for file format recognition and attribute access which match the function prototypes which the LEA Object expects. These are defined below. All the functions used by the LEA Object within the DLL must use the stdcall calling convention (the same calling convention as Windows API functions).

The DLL file name in the script file will not usually include path information. If the path is not specified then the following directories will be searched for the DLL

1. The directory containing the application's EXE file
2. The application's current directory
3. The Windows System directory (usually C:\WINDOWS\SYSTEM on Windows 95/98/ME and C:\WINNT\SYSTEM32 on NT/2000 machines)
4. The 16-bit System directory (Windows NT/2000 only, usually C:\WINNT\SYSTEM)
5. The Windows directory (usually C:\WINDOWS on Windows 95/98/ME and C:\WINNT on NT/2000 machines)
6. The directories specified by the PATH environment variable

Format recognition

The format recognition function should accept a Windows file handle as its single argument and return an integer which equals the value specified in the script file as the return value if the file is of the required format.

The function exported from the DLL should match the description below:

int __stdcall xxxx(HANDLE hFile);	C++ prototype
function xxxx(hFile: THandle): integer; stdcall;	Pascal forward declaration

If the same DLL function is used to recognise multiple file formats in the LEA Object, the function will be called only once for each file, and the result compared with each expected return value in turn.

See Script file format recognition entry layout for details of how to specify a DLL function for format recognition in a script file.

Attribute Access

Attribute values can be read from LEA Object files using a custom DLL function. To use a DLL for LEA Object attribute access, the DLL must export initialisation functions which correspond to the prototypes below.

The function names in the script file are matched case-sensitively with the function names from the DLL.

• Open function

  This function will be called once, when the LEA Object file is opened. .

  HANDLE __stdcall xxxx(char* filename);	C++ prototype
  function xxxx(filename: pchar): THandle; stdcall;	Pascal forward declaration

  This function should return an open Windows file handle to the LEA Object file. Since the file may already be open within the LEA Object, the share mode used must not be exclusive. The file handle returned by this function will be passed as an argument to the attribute reading function (below).
  This function can be used to read the attribute values into local variables, or to allocate local resources used in the file access.

• Close function

  This function will be called once when the LEA Object file is closed

  void __stdcall xxxx(HANDLE fHandle);	C++ prototype
  procedure xxxx(fHandle: THandle); stdcall;	Pascal forward declaration

  The file handle passed as an argument is the handle returned from the open function above. This function should close the file handle and dispose of any local resources allocated when the file was opened.

• Verification function

  This function will be called for each attribute when the DLL function is linked into the LEA Object, to verify that the attribute is supported.

  bool __stdcall xxxx(int iattr);	C++ prototype
  function xxxx(iattr: integer): boolean; stdcall;	Pascal forward declaration

  This function verifies that the attribute is supported by the DLL. The interface to this function may change in later versions of the LEA Object. This function should return true (not zero) for all attribute numbers supported by this DLL.

• Attribute read function

  The function specified in the attribute access section of the script file is called to return the value of the attribute for the current file. If necessary, different attributes may use different functions within the DLL to return their value, or even different DLLs (in which case each DLL must have its own set of open, verify and close functions

  void* __stdcall xxxx(HANDLE fHandle, int iformat, int iattr);	C++ prototype
  function xxxx(THandle: fHandle; iformat, iattr: integer): pointer; stdcall;	Pascal forward declaration

  The type of pointer returned must match the type of the variable specified in the LEA Object INI file:

  LEA Object attribute type	Pointer return type
  STRING	null-terminated single-byte character array
  INTEGER	4-byte integer
  FLOAT	8-byte floating point value
  TRUEFALSE	single-byte value (0=false)
  DATETIME	8-byte Microsoft DATETIME value

Script file DLL Initialisation section

Each DLL referenced in an attribute access section of a script file must also have an initialisation section which lists the function names of the open, verify and close functions:

[DLLNAME]
open=OPENFUNCNAME
close=CLOSEFUNCNAME
verify=VERIFYFUNCNAME

where:

DLLNAME is the file name of the DLL, which must match exactly the DLL name specified in the attribute access script entry.

OPENFUNCNAME, CLOSEFUNCNAME, and VERIFYFUNCNAME are the names of the initialisation functions within the DLL, as described above. Note that these function names should match exactly the function names explorted from the DLL. You can examine the exported function names using a utility such as QuickView.

Implementing LEA Objects as COM Servers

The standard LEA Objects are implemented using COM Automation interfaces. This enables each LEA Object to act as a 'plug-in' component.

The standard LEA Objects are each implemented by a single COM class that supports a number of predefined interfaces:

• ILEAFileRecognition
• ILEAReadAttributes
• ILEAReadSubObject

These interfaces are defined in the LEAOBCOM.DLL type library

IDL definition of ILEAFileRecognition interface:

[
 uuid(A65472A0-5323-11D4-B3F3-444553540000),
 version(1.0),
 dual,
 oleautomation
]
interface ILEAFileRecognition: IDispatch
{
 [id(0x00000001)]
 HRESULT _stdcall FileIsFormat([in] BSTR filename, [in] long ifmt, 
    [out, retval] VARIANT_BOOL * Value );
};

This interface contains one method - FileIsFormat - which is called to determine whether the file specified by filename is of the format specified by ifmt - the format code. This method may be called multiple times with the same filename argument for different format codes.
This interface must be implemented if the format recognition method for any of the defined formats is INTERNAL (see Format Defintion above)

IDL definition of ILEAReadAttributes interface:

[
 uuid(48A50CE2-518A-11D4-B3F3-444553540000),
 version(1.0),
 helpstring("Interface to be implemented by derived LEA Objects"),
 dual,
 oleautomation
]
interface ILEAReadAttributes: IDispatch
{
 [id(0x00000003)]
 HRESULT _stdcall OpenFile([in] BSTR filename, [in] long ifmt, 
    [in] VARIANT_BOOL writeable );
 [id(0x00000004)]
 HRESULT _stdcall GetMaxLogicalFiles([in] BSTR filename, [out, retval] long * Value );
 [id(0x00000005)]
 HRESULT _stdcall OpenLogicalFile([in] BSTR filename, [in] long ilogfilenum );
 [id(0x00000006)]
 HRESULT _stdcall GetAttribute([in] BSTR filename, [in] long ilogfilenum, 
    [in] long iattr, [out] TAttrStatus * Status, [out, retval] VARIANT * Value );
 [id(0x00000008)]
 HRESULT _stdcall CloseFile([in] BSTR filename );
 [id(0x00000009)]
 HRESULT _stdcall GetObjName([in] BSTR filename, [in] long ilogfilenum, 
    [out, retval] BSTR * Value );
 [id(0x0000000A)]
 HRESULT _stdcall GetObjShape([in] BSTR filename, [in] long ilogfilenum, 
    [out, retval] TLEAShape * Value );
};

This interface must be implemented if the attribute access method for any of the defined formats is INTERNAL (see Format Defintion above).

When an input file is opened as an LEA Object, the ILEAReadAttributes methods will be called in the following order:

After the format of the file has been verified (via either the ILEAFileRecognition interface, through file extension matching, or a script entry), the OpenFile method is called: ifmt is the format code, and writeable specifies whether the file should be opened read-only (false) or read-write (true). Use this method to allocate resources that will be required when reading the input file.
GetMaxLogicalFiles. This method should return the index number of the last conceptual logical file contained within the input file (ie if there are three logical files, the first logical file is index 0, and the last is index two). If there are no logical files, set Value to zero.
OpenLogicalFile will be called for the logical file index number to open. This function could be used to read the attribute values into internal variables If there are no conceptual logical files, this function can do nothing.
GetObjName is called for the specified logical file number ilogfilenum. The object name is one of the LEA Base Attributes (see below) and is retrieved from the file using this method.
GetObjShape is called for the specified logical file number. The object shape is one of the LEA Base Attributes. This determines the geographical extent of the object referred to by the file. Set Value to one of the TLEAShape constants defined in the LEAOBCOM type library:

[
 uuid(35211F00-519F-11D4-B3F3-444553540000),
 version(1.0)
]
typedef enum tagTLEAShape
{
 shpUNKNOWN = 0, 
 shpPOINT = 1,   
 shpLINE = 2,   
 shpPOLYGON = 3
} TLEAShape;

GetAttribute is called for each of the defined attributes for which the access method for the current file format is INTERNAL. iattr is the Attribute Code (defined above - see Attribute definition). Value should be set to the value of the attribute, bearing in mind that the value must be converted from an VARIANT type into either a STRING, INTEGER, FLOAT, BOOLEAN or DATETIME type.Status should be set to one of the TAttrStatus constants defined in the LEAOBCOM type library:

[
 uuid(8DB6BA2B-4CDE-11D4-B3F3-444553540000),
 version(1.0)
]
typedef enum tagTAttrStatus
{
 asUNDEFINED = 0, /* attribute value is undefined for this format */
 asOK = 1,        /* attribute value is OK */
 asCONV = 2,      /* error converting attribute value into required type */
 asRANGE = 3,     /* attribute value out of range */ 
 asABSENT = 4     /* attribute is absent */
} TAttrStatus;

CloseFile is called once when the input file is closed. This method can be used to free resources allocated in the OpenFile method.

IDL definition of ILEAReadSubObject interface:

[
 uuid(B017372B-D0C0-4315-A6FF-A0BF567C8575),
 version(1.0),
 helpstring("Interface used for multiple objects per logical file"),
 dual,
 oleautomation
]
interface ILEAReadSubObject: IDispatch
{
 [id(0x00000001)]
 HRESULT _stdcall GetSubObjectCount([in] BSTR filename, [in] long ilogfilenum, 
    [out, retval] long * Value );
 [id(0x00000002)]
 HRESULT _stdcall GetSubObjectAttribute([in] BSTR filename, [in] long ilogfilenum, 
    [in] long isubobj, [in] long iattr, [out] TAttrStatus * Status, 
    [out, retval] VARIANT * Value );
};

This interface is optional and should only be implemented if the LEA Object contains conceptual sub objects (see base attributes below)

If this interface is implemented by the object, the GetSubObjectCount method is called after ILEAReadAttributes::OpenFile and ILEAReadAttributes::OpenLogicalFile methods have be called. This method should return the index number of the last conceptual sub-object (the index of the first sub-object is zero).
The GetSubObjectAttribute method replaces the ILEAReadAttributes::GetAttribute method: isubobj is the index of the sub-object.

Base Object Attributes

All LEA Objects have the following attributes:

• File name - full DOS or UNC path (or URL) of the file containing the LEA Object (attribute type string)
• Volume Label - name of the file-system, disk, or storage identifier on which the file containing the LEA Object resides (attribute type string)
• File Owner - the user-name of the owner of the file containing the LEA Object - this can be detected on NTFS and Netware filesystems (attribute type string)
• File size (bytes) - the size of the file containing the LEA Object, in bytes (attribute type integer)
• Date last modified - the last modification date/time of the file containing the LEA Object (attribute type datetime)
• Logical file number - if this is zero, then the logical file is the same as the physical file. If the logical file number is greater than zero, then the current LEA Object is stored within a concatenated sequence of logical files within one physical file on tape or disk. (attribute type integer)
• Logical file count - a file-system file can contain more than one LEA Object. For example, a number of Wireline Log Objects can be contained in a file of LIS-TIF format. The logical file count lists the total number of logical files contained within the physical file-system file. If this number is zero, then the logical LEA Object is contiguous with the physical file (attribute type integer).
• Object number - if an LEA Object is conceptually sequential, then the Object number attribute is non-zero (for example a Wireline Curve Object, or a Seismic Trace Object) (attribute type integer)
• Object count - the total number of LEA Objects of the current type within the current container or parent Object (attribute type integer)
• Format - file format description (attribute type string)
• Shape - the geographical shape of the LEA Object - NONE, POINT, LINE or POLYGON (attribute type string) - by default this is NONE. Other LEA Objects may override this implementation.
• Name - the name of the LEA Object, used when reconciling objects of more than one type (attribute type string) - the default implementation of this in the base LEA Object is to use the filename with no extension. Other LEA Objects may override this implementation.
• Extension - the file extension of the file, usually indicative of the file format.

These attribute names and descriptions are listed in the INI file LEAOBJ.INI which can be found in the LYNXSYS directory. All LEA Objects inherit these attributes. The Base LEA Object (described in BASEOBJ.INI, implemented by COM Object LEAObCom.FileObject accepts all file formats, and will display these attributes for any file-system file.

Key Attributes

LEA Object types all have key attributes which are the essential pieces of information for the particular object type. LEA applications use these key attributes to provide database indices (see Dougal and Florence - the LEA Data Catalogue Designer and Builder).

The default key attributes for the base object are:

1. File name
2. Logical file number
3. Object number

Locale Independence

LEA date/time string representation

There are almost limitless ways to represent date and time values as a string. The default format used on each PC varies according to the locale and the Regional Settings (specified via the Control Panel).
LEA applications present date/time values in the form described below, and expect input strings containing date/time values also to be in this form.

(DD/MM/YYYY) (hh:mm:ss)

Some examples follow:

12/1/1999

specifies 12th January 1999

15:30:00

specifies half past three in the afternoon

25/6/1999 11:15:00

specifies quarter past eleven in the morning, 25th June 1999

Floating point numbers in INI files

All LEA INI (and parameter) files expect the floating-point numbers they contain to use the dot ( ' . ' ) character as the decimal separator. Floating point values will usually be displayed to you in LEA applications using the local decimal separator specified in the Regional Settings of the Control Panel on each PC. However, when editing INI files directly, it is important to remember to use dot characters to specify floating-point numbers.

Initialisation Errors

Listed below are the error messages that may be generated as the LEA Object's INI file is read. All these errors will cause the initialisation of the LEA Object to fail.
These errors all imply that the INI file format is incorrect or out of sync with the DLL libraries used by applications - the file may have been accidentally edited by hand, the Object Wizard may have failed to save a file correctly due to errors, or a new installation may have failed to upgrade the correct files.

• General INI file errors
• Format definition errors
• Attribute definition errors
• Script file errors
• DLL errors

General INI file errors

INI file name missing section section
Error code 502

The named section is missing from the named INI file.

Filename is not an LEA Object INI file
Error code 504

The named file is not recognised as an LEA Object INI file.
LEA Object INI files must have a [LYNX] section with the entry

TYPE=LEAOBJECT

This error may be generated when attempting to create a user-defined LEA Object type.

COM ProgID not found in either [com_classes] section of LEAOBJ.INI or [object_description] section of filename
Error Code 505

In order to create COM objects from a DLL, the progid must be read from the LEA Object INI file. This progid is looked up in the registry to find the identifier of the COM class to create. The progid is usually the name of the DLL containing the COM class, followed by a period and the name of the CoClass to create.
For LEA Objects defined solely by scripts, the progid should be LEAObCom.FileObject.

INI file name does not match version Vx.y
Error Code 506

There is a mismatch between the version range specified in the INI file, and the version number retrieved from the compiled code.

Bad COM ProgID name specified in INI file
Error Code 507

The specified progid does not exist in any registered COM server, or in the DLL specified by the dll key from the [OBJECT_DESCRIPTION] section of the LEA Object INI file.

Error registering COM server name
Error Code 508

Before a COM server can be used, it must be registered on the local PC. This error may occur if you do not have permission to write keys to the registry.

Format definition errors

Name for format code n not found in [FORMAT_NAMES] section of INI file name for current language setting
Error code 301

The format names used by LEA Objects are language-dependent. The actual names of language-dependent sections in the INI file depends on the language prefix used for the current language. The error message text will display the name of the section it is looking for.

Invalid format recognition method keyword for format code n in section [FORMAT_RECOGNITION] of INI file name
Error code 302

The method used to recognise each format must be specified from a list of valid keywords. See Format Recognition above.

Invalid attribute access method for format code n in section [ATTRIB_ACCESS] of INI file name
Error code 303

The method used to read attributes for each format must be specified from a list of valid keywords. See Attribute Access above.

Attribute definition errors

Name for attribute number n not found in [ATTRIB_NAMES] section of INI file name for current language setting
Error code 401

The attribute names used by LEA Objects are language-dependent. The actual names of language-dependent sections in the INI file depends on the language prefix used for the current language. The error message text will display the name of the section it is looking for.

Invalid attribute type keyword for attribute number n in section [ATTRIB_TYPES] of INI file name
Error code 403

The type of each attribute must be specified from a list of valid keywords. See Attribute Definition above.

Script file errors

File name not found
Error code 101

The named script file specified in one of the format recognition or attribute access INI file entries could not be found. See Script Files above for details of the directories searched for script files, and Format Recognition and Attribute Access for details of how to specify the script to use.

File name is not a script file
Error code 109

The named file is not recognised as an LEA Object script file.
The file should be an ASCII file with an INI-style layout (divided into named sections, with the section names delimited by [ and ].
The first section in the script file must be [LYNX] with an entry

TYPE=SCRIPT

denoting that the file is an LEA Object script file.

Section section not found in script file name
Error code 102

The specified section is missing from the script file. See Format Recognition and Attribute Access for details of how to specify the script to use.

Attribute/format key n not found in section section of script file name
Error code 103

There is no entry for the specified attribute/format number in the named section of the script file.
For Format Recognition, the file and section containing the format recognition script are specified for each format.
For Attribute Access, the file and section containing the attribute access scripts are specified on a per format basis, and each attribute must have an entry in the specified script section.

Illegal data conversion keyword for type keyword found in script file name, section section, key n
Error code 104

Each variable type has a list of valid conversion types. See Format Recognition Scripts and Attribute Access Scripts for valid combinations.

Illegal value value in LIMITS for type keyword found in script file name, section section, key n
Error code 105

The LIMITS string is a list of fields which define either a range of alternative acceptable values, or the minimum and maximum acceptable values. The meaning of the fields depends on the variable type. See Format Recognition Scripts and Attribute Access Scripts.

No LIMITS string found for format key n in section section of script file name
Error code 106

For format recognition scripts, a list of alternative or minimum and maximum acceptable values must be supplied.

Invalid search string keyword for key n in section section of script file name
Error code 107

The search string must be specified from a list of valid keywords.
See Format Recognition Scripts and Attribute Access Scripts.

FIND info string invalid for attribute/format key n in section section of script file name
Error code 108

The INFO string associated with the FIND keyword for the specified attribute/format number is invalid. There is probably a field missing from the string. Check that the string matches the definition for Format Recognition scripts or Attribute Access scripts.

DLL errors

DLL file name not found
Error code 201

The DLL specified in a script entry or as a COM server could not be found. If the specified DLL name does not contain a directory path, the following locations are searched for the DLL:

1. The directory containing the application's EXE file
2. The application's current directory
3. The Windows System directory (usually C:\WINDOWS\SYSTEM on Windows 95/98 machines, and C:\WINNT\SYSTEM32 on NT machines)
4. The 16-bit System directory (Windows NT only, usually C:\WINNT\SYSTEM)
5. The Windows directory (usually C:\WINDOWS on Windows 95/98 and C:\WINNT on NT machines
6. The directories specified by the PATH environment variable.

See Format Recognition using a DLL,Attribute Access via DLL and Implementing LEA Objects as COM servers.

Function name not found in DLLname
Error code 202

The specified function is not present in, or is not exported from the specified DLL. The functions exported by a DLL can be listed using the Quick View utility (by right-clicking on the file in an Explorer window).
See Format Recognition using a DLL and Attribute Access via DLL.

File Errors

Listed below are error messages that may occur during the normal use of LEA Objects.

File does not exist

The file specifed for opening does not exist.

Format unknown

The specified file could not be recognised as any of the formats for the current LEA Object type. Formats and the method used to recognise them are listed in the [FORMAT_RECOGNITION] section of the LEA Object's INI file.

File is read-only

An attempt was made to write attribute data back to the LEA Object file, when it was opened in read-only mode, or the file has the read-only flag set

See also:
[Florence - LEA Catalogue Builder]
[Dougal - LEA Catalogue Designer]