Unix and Linux
with Application Environment
C# and .NET
Integration and Supply
Database Connectivity and Tag Data Access
All GLG drawings and components are compatible and may be used interchangeably between various Unix, Linux and Windows platforms, as well as between C/C++, Java, ActiveX, C# and VB.NET environments.
The Java version of the GLG Toolkit is certified 100% pure Java, and is by definition cross-platform. The same GLG-based Java application can be used on both Unix, Linux and Windows, as well as in any Java-enabled browser, including IE, Mozilla, etc.
The GLG APIs for Java and C# differ only syntactically from the C/C++ API, which makes it trivial to port GLG applications from C/C++ to Java and C# or vice versa, reusing the programming logic.
The GLG C/C++ Programming API is cross-platform and identical on both Unix/Linux and Windows. It provides a choice of the GLG Generic API as well as native containers for a variety of programming environments.
If the GLG Generic API is used for displaying GLG drawings, all code is cross-platform and may be compiled and run on both Unix, Linux and Windows platforms.
If native containers (such as a Qt/Gtk/Motif Widget, an MFC class, etc.) are used to integrate GLG into the native GUI, only the code that inserts the native container is platform-specific, while the code which implements application logic is cross-platform and can be reused between Unix, Linux and Windows.
provides two ways to use its graphics in
a programming environment: the Generic API and native
can be used to write
cross-platform code that can be compiled and run in both Unix, Linux
Windows environments. When the Generic API is used, the application
loads and displays the drawing using the GlgLoad and GlgInitialDraw
methods, letting the Toolkit handle all details of the native
GlgObject component = GlgLoadWidgetFromFile( "dial1.g" ); // Load
GlgInitialDraw( component ); // Display
uses a native GUI, the Toolkit
provides a variety of native containers which integrate the
drawings into the GUI. To embed a GLG drawing, one of these containers
is inserted into the GUI in the usual platform-defined way. The
container then loads and displays an application-specified drawing,
which can contain one or several GLG components. The application then
uses the container's GLG Programming API to supply
In addition to the GLG Generic API, the following native programming containers are provided:
A GLG Wrapper Widget is used to integrate GLG components and drawings into an Xt and/or Motif environment. The Wrapper Widget's DrawingFile resource specifies the GLG drawing to load and display inside the Wrapper Widget. When the drawing is loaded and displayed, the application uses the GLG Programming API to set resources of the drawing and supply dynamic data for updates.
Both the Xt and Motif-based versions of the Wrapper Widget are provided. An X11-based equivalent of the GLG wrapper is also available. The GLG/Qt, GLG/GTK and GLG/GTKMM wrappers are also provided.
An MFC class is provided for integrating GLG components and drawings into Visual Studio's C++ environment. The MFC-based GLG control is added to the application as a regular MFC control. It then loads and displays a GLG drawing, and provides GLG API methods for accessing resources of the drawing and supplying data for updates.
A Windows Custom Control is provided for low-level Win32 integration. The GLG Generic API can be used for developing cross-platform applications that share the HMI source code on between Windows and Linux/Unix platforms. Three levels of the GLG API are available: Standard, Intermediate and Extended.
A GLG C# User Control and a .NET Class Library are provided for developing Windows Forms application in C# and VB.NET. The User Control loads and displays a GLG drawing, and provides GLG API methods for accessing resources of the drawing and supplying data for updates. All GLG APIs - Standard, Intermediate and Extended - are available in C#.
An ActiveX control is a binary alternative to the C# User Control; it may be used to integrate GLG drawings into the Visual C++, C# and Visual Basic environment. The ActiveX Control's DrawingFile or DrawingURL properties define the GLG drawing to be loaded and displayed inside the ActiveX Control. The application then uses the control's GLG API methods for accessing resources of the drawing and supplying data for updates. The ActiveX control can use the OpenGL driver to perform hardware-accelerated rendering of complex 3D drawings. The ActiveX Control provides methods of the Standard, Intermediate and Extended API.
The 100% pure Java bean is used to integrate GLG components and drawings into Java applications.
The Glg Bean is inserted in a Java application by adding it as any other Java bean. The bean's DrawingFile or DrawingURL properties define the GLG drawing to be loaded and displayed inside the bean. The application then uses the bean's GLG API methods for accessing resources of the drawing and supplying data for updates. The Toolkit also provides access to Java classes of individual GLG objects inside the drawing, which may be used to direct access to the drawing's components.
The Programming API for the Java version of the Toolkit has only minor syntactical differences from the C/C++ API, making it trivial to port C/C++ GLG applications to Java and vice versa. Click here for more details on the Java version of the Toolkit. All GLG APIs - Standard, Intermediate and Extended - are available in the Java version of the Toolkit.
The Toolkit's API is used by an application to push the data into the GLG component for graphical display and updates. The Toolkit is designed to provide comprehensive and flexible front-end graphics capabilities with an open data API, allowing an application designer to easily integrate with data sources ranging from a variety of databases to socket connections and third-party data acquisition products.
data access mechanism makes data
supply extremely simple, flexible and intuitive. For example, the
container.SetDResource( "dial1/Value", 5. );
// Set new resource value
container.Update(); // Display new value
updates the value of a dial named "dial1" in the GLG drawing embedded into the application. GLG updates are data-driven, so the drawing is updated only when the new data arrives, with no CPU cycles wasted for idle polling.
Since updating the graphics is the most CPU-intensive operation, resource setting may be "batched" to increase performance. For example, the following code:// Set all new values
nature of GLG drawings makes the
Toolkit extremely well suited for large applications, which have
complex hierarchy of components (dials, meters, tanks, etc.) and may
use a table-based mechanism for mapping component instances to data
Data Access Mechanism was introduced in to simplify data
connectivity to external
process databases. While resources reflect the object hierarchy of the
drawing, tags are global names which can be used for supplying data
without knowing the exact structure of the drawing. The tags are
associated with resources in the Graphics Builder and then used to
supply real-time data without using resource paths at run-time.
Graphics Builder provides a mechanism for integrating a Custom Tag Data Browser into the
Builder, so that the end user can browse application database and
select tags from the list.
provides transparent handling of object
selection, which functions regardless of display size and resolution,
state of the pan and zoom, or shape of the object. The Toolkit provides
two mechanisms for handling object selection:
events may be added to objects
Enterprise Edition of the Builder or programmatically. Both mouse click
mouse over events as well as integrated tooltips are supported.
The Toolkit can also handle feedback of mouse movement or clicking. The integrated mouse click feedback can be used to alter an object's appearance, and the mouse over highlight can be used to implement "hot spots."
Input callback is
invoked when user interacts with any of the sliders, knobs, buttons or
toggles in the drawing. When the input callback is invoked, it receives
a message object containing all information about the control which
triggered the event. The program can use the GLG Programming API to
query the message object's resources and handle user interaction with
ease. The Trace callback can
be used for reacting to the low-level native windowing system events.