GX .NET APIs

The Geosoft GX .NET API has two flavors consisting of 2 assemblies each. Refer to the .NET API reference links in the Documentation by Release.

The first flavor's namespace ends in GXNet and is used for most extensions and standalone programs. This API is not thread safe and all API calls should be used inside a single thread only. The second's namespace ends in GXNetX and could be used where multiple threads uses the API at the same time. Each thread should have its own CGX_NET or CGXNETCore context object which, will be the first argument passed to static methods and object creation methods.

The 2 assemblies split the available classes roughly into what is considered "Core"  engine functionality (Geoengine.Core.* namspace) and classes that are closer to what the full Oasis montaj Desktop suite offers (Geosoft.Desktop.* namspace). 

C# Examples

See GXDotNet repository examples

GX API for .NET

The GX API can by used to create .NET DLLs that can be called directly from a Geosoft menu.

See the Documentation by Release for links to the .NET API reference documentation.

Connecting your code to the Geosoft environment

There are several different ways of connecting your code to the Geosoft environment of your choice:

• GX based - In this scenario, which is the simplest, you create a GX which calls an exported function or functions in your DLL. That function receives a "handle" to the Geosoft object, which is necessary to interact with the API functions. Upon completion, the DLL function returns control to the GX. In this scenario your function behaves similarly to an API function, in that its lifespan is limited to the GX execution.
• .NET based - A function exported from a .NET assembly can be called directly from a menu item without wrapping it in a GX, but is otherwise the same as above.
• External application - A standalone program can be built which creates a separate instance of the Geosoft executable in memory and accesses databases or maps. Some parts of the API are not available using this method. Furthermore the external application can not interact with a running instance of the Geosoft program. However, a GX can be created to prepare your Geosoft project so that it can be opened and processed by the external application, which can be run using the GX iShellExecute_SYS() method. The Python package also allows you to create fully 64-bit external applications that access the GX API.
• GeoXTool application - This is a DLL based program that becomes part of the running instance of Geosoft. A GeoXTool is able to interact with the program and 'react' to user actions such as changing line, selecting data or zooming/ panning a map. This type of tool is most difficult to create but very powerful.

GeoXTool Application

A GeoXTool will launch as a dockable window inside the Oasis montaj. Once launched from a GX the process, it stays resident and responds to events within the environment. The tool should implement a user interface and once launched, it will be saved with the current project and recreated if the project is opened again. The CMETA object passed to bInitializeToolControl can be used to serialize information into the project and will automatically be recovered when the project is closed and reopened.

Creating a GeoXTool

By creating a control descending from ToolControl (9.10 reference) most of the plumbing is already taken care of.

GeoXTool API

This object can respond to the following events in the environment:

1. 1. GeneralInfo
   2. ChangeArea
   3. ChangeLocation
   4. ChangeProjection

Sample

A sample of a .Net based GeoXTool with a GX that launches can be found at XToolControl (9.10).