GLG Toolkit: Integration with Application Environment

Cross-Platform Use

   Unix and Linux
   Windows
   Java

   HTML5 & JavaScript
Integration with Application Environment

    C/C++, Windows
    C/C++, Linux/Unix
    Java
    C# and .NET
    ActiveX Control
    HTML5 & JavaScript
Data Integration and Supply

Data Connectivity Using Tags

Object Selection

User Interaction

Cross-Platform Use

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#, VB.NET and HTML5 / JavaScript 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.

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 Web Edition of the Toolkit uses HTML5 and JavaScript to deploy GLG drawings on a web page in a browser. The GLG JavaScript Library implements full GLG run-time functionality present in the GLG C/C++, C# and Java libraries, allowing the same graphical page and programming logic to be shared between the desktop, web and mobile versions of an application.

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.

Integration with Application Environment

The Toolkit provides two ways to use its graphics in a programming environment: the Generic API and native containers.

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 windowing environment:

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.

Three levels of the GLG API are available: Standard, Intermediate and Extended.

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.

Data Integration and Supply

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.

Supplying Animation Data via Resources

The following provides an example of pushing dynamic data into the Value resource of a dial widget named Dial1 inside a GLG drawing:

    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
   
drawing.SetDResource( "Dial1/Value", value1 );
   
drawing.SetDResource( "Dial2/Value", value2 );
   
drawing.SetDResource( "Dial3/Value", value3 );
   
    drawing.Update();   // Refresh display

Supplying Animation Data via Tags

The Tag Data Access Mechanism simplifies data connectivity to external process databases. While resources reflect the object hierarchy of the drawing, tags are global. Each tag defines a name of a data source variable that supplies data for the dynamic attribute the tag is attached to.

A tag is assigned to a dynamic attribute in the drawing. For example, a tag Voltage may be assigned to the Value resource of a dial widget, and the dial may be animated at run-time as follows:

    drawing.SetDTag( “Voltage”, volt_value );    // Set new tag value
    drawing.Update();   // Refresh display

Note that since the tags are global, the dial doesn't have to have a unique name in the drawing, and the application code doesn't need to know the exact resource path to animate it with data.

An application can query a list of all tags defined in the drawing and use this information to animate the drawing with values obtained from the corresponding data sources, without knowing the exact structure of the drawing. The use of tags makes it possible to develop a generic viewer application that can load and animate an arbitrary GLG drawing.

A Custom Tag Data Browser may be integrated with the Graphics Builder or HMI Configurator, so that the user can browse application data sources and select tags from the list in the data browser.

Tag assignment may be done at design time in the editor, or at run-time in the application code.

Object Selection

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."

User Interaction

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.