Info Topics
GLG Application Design Tips: Scalable HMI Design
Component Reusability & Template Management
- Custom Widgets for Rapid Deployment: Standardize frequently used objects by converting them into Custom Widgets. By adding these to the Widget Palettes, developers can drag and drop pre-configured components in the drawings using the GLG Builder. The Custom Widget can also be made available to end-users within the GLG HMI Configurator.
- Subdrawings for Global Updates: When using multiple instances of a graphical object (e.g., valves, motors), implement them as Subdrawings. This creates a master-template relationship; modifying the source subdrawing automatically propagates changes to every instance across all project files, eliminating the need for manual edits across multiple drawings.
Data Connectivity & Integration
- Tag-Based Data Access: Use Tags instead of Resources for data supply. Since Tags are accessible directly via their TagSource, this eliminates the need for full resource paths. This approach decouples the data layer from the UI, allowing for more flexible system scaling and simplified backend updates.
- Resource Management: Reserve Resources for configuring drawings and accessing internal object properties that do not require external data links. Maintaining a clear separation between Tags and Resources ensures that operational data remains independent of UI configuration.
Architecture: The "Universal Viewer" Model
Design applications to be "drawing-agnostic" to eliminate the need for source code changes when adding new displays. This is achieved through the following approach:
- Dynamic Data Tag Discovery: Instead of hard-coding specific tag names, utilize runtime introspection to query the list of tags defined in the drawing. By dynamically identifying the tags used for data updates at load time, the viewer can automatically bind and update data streams without prior knowledge of the drawing's internal structure.
- Command Handling: Utilize Commands attached to objects in the drawing to handle interactive events (e.g., Write Value, Popup Dialog, Navigate) as shown in the SCADA Viewer example. A Command object contains parameters that can be defined in the GLG Builder. This allows the source code to remain generic, processing diverse user interactions based on the object's metadata rather than the logic hardcoded in the source code.
- Widgets with Custom Logic: If an application contains graphical objects that require dedicated code to implement their behavior and user interaction, encapsulate them as special widgets as shown in the SCADA Viewer example. These widgets are detected at load time and automatically coupled with their supporting code, regardless of their location in the drawing, making it easy to reuse them in multiple drawings.
- Drawings with Custom Logic: For drawings that require custom update or user interaction logic, implement them as custom pages. These pages subclass the default page based on the drawing's PageType property to implement specific behavior on top of the default logic that handles standard data updates and command-based user interaction, as shown in the SCADA Viewer example.
Reference Frameworks
For rapid prototyping, use the pre-built source code provided in the
GLG Installation Directory:
- Simple Viewer (Monitoring-Only): A lightweight template for basic drawing display and real-time data updates. It is optimized for high-performance visualization, making it ideal for read-only dashboards and high-speed monitoring applications with minimal overhead.
- SCADA Viewer (Monitoring & Control): A comprehensive framework for high-interactivity applications. It includes built-in support for interactive command handling, backend write-backs, popup dialogs, alarm displays, multi-level page navigation and drill-downs. Easily extend the logic by mapping custom commands to your graphical objects to support custom logic and user interactions.
Integration Strategy: These frameworks are "drawing-agnostic." To transition from a prototype to a production-ready application, simply swap the sample .g drawing files in the
drawings directory with your own drawings and link your data source by providing custom code in the
LiveDatafeed module. Alternatively, the frameworks include built-in code to leverage the
GLG Data Gateway, enabling the application to obtain real-time data from and send command write-backs to a remote server.
Because the viewer logic queries the list of Data Tags defined within your drawings at run-time, the system is highly scalable; you can add new objects or entire screens without changing the underlying source code.
Using Resource and Tag Wildcards
Functions that set resource or tags values support * and ? wildcards for pattern matching. The asterisk (*) matches any sequence of characters, and the question mark (?) matches any single character.
To enable wildcard matching, prefix the resource or tag name with "$!". For example,
"$!Clear*" will target all tags with names beginning with "Clear".
When using wildcards in resource paths, the wildcards prefix must be added to each level of resource hierarchy where pattern matching is required. For example, the following string targets all nested elements with names beginning with "Element" inside parent objects with names beginning with "Group":
$!Group∗/$!Element∗/LineWidth
NOTE: Wildcards can only be used for matching named object resources; they cannot be used for matching default attribute names (e.g.
LineWidth,
FillColor).
Resource Access Optimization
If null is passed as the
resource_name parameter of methods for setting and querying resources, the data object supplied by the
object parameter will be used directly, avoiding an overhead of a resource search. This can be used to optimize performance
when the same resource is accessed repeatedly. The
GetResourceObject method of the
Intermediate API may be used to obtain an object ID of a data object once and then use it repeatedly.
For example:
GlgObject data_obj = viewport.GetResourceObject( "WaterTank/Level" );
...
if( data_obj != null )
data_obj.SetDResource( null, new_water_level_value );
The AddDataSampleNode method of the Intermediate API can also be used instead of setting values of chart entry points to prefill a chart with a large number of data samples.
Container Objects
GLG
Container objects include
ARRAY (Dynamic Array),
LIST and
VECTOR objects.
The following composite objects are also
containers and may be used with container methods:
- Viewport is a container of objects rendered inside it, which can be accessed as elements of the viewport.
- Group is a container used to group objects in a drawing.
- GIS Object is a container of GIS icons displayed on top of the map in lat/lon coordinates.
- Polygon, Spline and Connector objects are containers of their control points, which can also be accessed as their elements.
When a
container object is created, one of the creation parameters is the type of elements it will contain (see
GlgContainerType for more information):
There are three types of containers:
- ARRAY "Dynamic Array" grows its size as needed when new elements are added. It is used by objects, such as groups and viewports, that need to hold their subobjects, as well as by polygons that use it to contain their control points.
- LIST "List" provides an efficient handling in cases when elements need to be frequently added and removed. It is used by chart plots to keep their data samples.
- VECTOR "Vector" is a fixed size container mostly used by the Toolkit's internals.
There are two flavors of
container methods:
- Methods that use indexing to access container's elements provide convenient access to elements of the dynamic array containers. These method still work on both arrays and lists, but are less efficient when they are used for list objects because they require traversing list elements.
- Methods that iterate a container or use its current position may be used with both dynamic array and list containers, and provide more efficient handling of list containers.
The Extended API provides additional methods for adding and deleting elements of a
container.
Custom Interaction Handlers
The Toolkit provides a number of
stock interaction handlers, such as
GlgButton,
GlgSlider, etc., which also use this interface. Custom interaction handlers may be developed to be used in the GLG editors as well as in the application at run time.
A
custom handler implements an application-specific logic for handling user interaction and is associated with a viewport in a GLG drawing the same way as the stock interaction handlers. In GLG editors, a custom handler is attached to a viewport or a light viewport by assigning the handler name as a value of the viewport's Handler attribute. To avoid error messages in case the custom handler is implemented only in the runtime application code, the custom handler name should start with the $ character, for example
"$SampleHandler".
Custom interaction handler code implements a single handler's
EntryPoint method that is invoked with different parameters to handle handler initialization and user interaction.
A custom handler is installed by registering the handler object as a named handler using the
AddHandler method, which takes the handler name and its entry point as parameters:
GlgObject.AddHandler( "$TestHandler", TestHandlerInterface );
This activates the custom handler in the application at run time.
Using Custom Handlers in the Graphics Builder
To activate the handler in GLG editors, the C version of the handler code can be added to the GLG Editor Custom Options DLL described in the OEM Editor Extensions, Custom Editor Options and Dialogs DLL section of the OEM Customization chapter of the GLG User's Guide and Builder Reference Manual.
Interaction Handler Methods
The following methods may be used by the handler's code:
Sample Implementation
Sample source code of a custom interaction handler is provided in the
src/SampleHandler/SampleHandler.cs file in the GLG installation directory.
The C version of the sample code is provided in the
src/SampleHandler/SampleHandler.c file and is integrated into the
GLG Editor Custom Option DLL to make the sample handler active inside GLG editors.
To test the the sample handler in the Graphics Builder, run the following script:
- On Linux/Unix:
<glg_dir>/editor_extensions/custom_option_example/run_option_example
- On Windows:
<glg_dir>\editor_extensions\custom_option_example\run_option_example.bat
then load the
sample_handler.g drawing into a Graphics Builder from one of the following locations:
<GLG_DIR>/editor_extensions/custom_option_example/sample_handler.g
<GLG_DIR>/src/SampleHandler/sample_handler.g
Start the prototype mode using the Run, Start menu option, then press the Skip Command button. Click on the buttons to interact with the handler: it will count clicks, and will also trace and display mouse coordinates.
1.9.1