ActiveX Controls Not Respecting Layering in HMI/SCADA Systems
When using ActiveX controls such as Industrial Gadgets in various HMIs, I cannot get native objects drawn in the HMI system using their drawing tools to stay on top of the ActiveX controls.
In WinCC the HMI design environment won't even let me put a native object on top of the ActiveX Controls.
In RSView i can put a native object (i.e. a rectangle) on top of the ActiveX at design time but it always ends up behind the ActiveX controls at runtime.
What causes this? Is this a bug in the ActiveX controls?
First, an important thing to realize is that ActiveX components are just that - components. They draw in an area provided by the container application (i.e. Visual Studio, the HMI, etc). They only draw in the area they are given and on the drawing plane they are given by the container. The layering of objects with respect to each other is managed by the container. An ActiveX control is totally unaware of other ActiveX components on the page. Although you may see a Z-order property on ActiveX controls, that is only a place for the container to show you the z-order, and the container is responsible for storing and respecting the z-order or layering of ActiveX controls with respect to one another.
Every HMI system has a choice to make when it supports ActiveX controls whether to draw the ActiveX control components in the same "layer" or "plane" as their native objects. Our experience has been that every HMI system we have used puts ActiveX components on a different layer or plane than the native objects drawn using the HMI/SCADA system's tools.
i.e.: if you can visualize looking at two sheets of glass or paper in edge view, with each piece of glass representing one of the layers or planes in the HMI screens, this is what you would see:
OR--------- ActiveX Plane
--------- Native Objects Plane
--------- Native Objects Plane
--------- ActiveX Plane
Within a Plane or Layer you can control the ordering of objects with respect to each other. This is commonly referred to as "Z-order". However you cannot control the ordering of objects with respect to each other if they are on different planes/layers. And we have yet to see an HMI system that lets you control which plane/layer is in front - i.e. native or ActiveX. Its always one or the other and is hard set for that HMI.
So using an example with some objects in each plane:
----object2-----
--object1---
-------------------------------------- ActiveX Plane
--native object1---
--native object2---
-------------------------------------- Native Objects Plane
In the above example, you can control the order of Object 1 with respect to Object 2, and of Native Object 1 with respect to Native Object 2. However, Object 1 and Object 2 will always end up on top of the Native Objects because the ActiveX plane is always drawn after the Native Objects plane.
With respect to WinCC, they always put the ActiveX Plane on top of the Native Objects Plane, and their design time environment does not lead you to believe that you can intermix them - if you try to put a native object on top of an ActiveX it won't allow you to because that would be intermixing of the planes.
With respect to RSView, they also always put the ActiveX Plane on top of the Native Objects Plane. However, in the design time, you can put objects behind one another in an apparent mixing of the planes. Reality is though at runtime, they always put the ActiveX Plane on top of the Native Objects Plane, so the ordering of native objects with ActiveX objects is not respected.
If you are also using our Symbol Factory ActiveX along with Industrial Gadgets, you should also read our FAQ regarding the Layering of Windowless and Windowed ActiveX Controls as that affects the ordering of objects within an ActiveX plane because of two different ActiveX drawing methods that Microsoft offered and promoted use of at different times in the history of the Windows Operating System.
In Summary:
- Layering of ActiveX controls with respect to native objects in an HMI is a function of the HMI's choice for whether they draw the ActiveX plane in front of the Native Objects Plane or vice-versa
- The storage and implementation of the layering of objects within a plane is handled by the container application, not by the ActiveX control.