Unix and Linux
C# and .NET
Integration and Supply
Data Connectivity Using Tags
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.
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.
The library uses HTML5 canvas to render graphics and supports all major browsers: Chrome, Firefox, Edge and Safari, as well as mobile browsers, and can be deployed across platforms on any device that has a web browser.
The Toolkit provides two ways to use its graphics
in a programming environment: the Generic API and native
The Generic API
can be used to write cross-platform code that can be compiled and
run in both Unix, Linux and 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
If the application 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 data.
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 GLG API is used by an application to push data into graphics for data-driven animation. 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 systems.
Any object or widget in the drawing may be
animated by pushing dynamic data values to an object attribute,
using one of the following methods:
While resources are hierarchical, tags are global and provide a
way to access attributes using a flat structure. The use of tags
makes it possible to develop a generic viewer application
that can load and animate an arbitrary GLG drawing without knowing
its resource hierarchy. The GLG
SCADA Demo provides an example of a GLG generic viewer.
drawing.SetDResource( "Dial1/Value", 5. );
// Set new resource value
drawing.Update(); // Refresh display
GLG updates are data-driven, so the
drawing is updated only when the new data are pushed into
graphics, with no CPU cycles wasted for idle polling.
Since rendering the graphics is the most CPU-intensive operation, resource settings may be "batched" to increase performance. For example, the following code uses only one graphical redraw to update all thee dials:// Set all new values
The Toolkit 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:
Custom selection events may be added to objects
using the Enterprise Edition of the Builder or programmatically.
Both mouse click and 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."
Similarly, the program's 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.