Modules, Panels, Child Panels
So far only a process image, a trend panel as well as some input dialogs were created. The results were viewed in the preview of the graphic editor and the preview was clear and sufficient.
Real plants, however, consist of several dozen or hundred process images so that you need an appropriate form of navigation and image management. In addition to the methods for opening dialogs (child panels) described in the chapter Creating Process Images - the Graphic Editor, this chapter goes more into detail and describes the "Window technics".
In a WinCC OA system, several user interfaces can run at the same time on the server. Thereby, it is irrelevant whether these UI managers run on the same (for example server) or on different computers. Typically, a user interface will be configured per each computer.
Each user interface can display one or more visualization modules. Thereby, such a module always represents an own program window regarding the operating system.
A so-called root panel will be opened in each module. This can either be a process image like the already created panel process.pnl or a user interface with further embedded modules in the root panel. In these modules, panels are opened as root panels.
Moreover, you can open a further module as an independent window through a module. If you close the calling (original) module or you change the root panel shown in that module, the called (new) module remains open.
The use of several modules is important when specific areas of visualization should remain open permanent and independent of the rest. In this way, on a computer with two monitors, one of the process images could remain open on the left and the alarm screen on the right. Still only one user interface manager will be required.
Without additional settings, the window of a module always possesses a tool bar and menus by default. These are hidden in most cases since the user should only navigate using the elements of the panels.
Further windows can be opened as child panels by each root panel. A child panel belongs to the root panel through which it was opened. When a root panel is closed, also the associated childpanels will be closed automatically. The display of the input dialog for valve V3 is meaningful only when the process image with the valve view V3 and its environment is visible.
You can open child panels and modules in many different ways depending on the task.
| Runtime behavior/ Positioning | Module/Root panel | Child panel |
|---|---|---|
| Centered regarding the screen | X | - |
| Centered regarding the calling panel | - | X |
| Arbitrary x/y position regarding screen | X | - |
| Arbitrary x/y position regarding the calling panel | - | X |
| Arbitrary relative x/y position regarding the calling point in the panel (e.g. always on the right above the device symbol). | - | X |
| Always in the foreground regarding all program windows (stayOnTop()) | X | - |
| In the foreground regarding windows of the own module, locked (modally) | - | X |
| Call from the root panel | X | X |
| Call from the child panel | X | X |
| Direct return values to the calling panel (Query and confirm dialogs) | - | X |
It is not easy to differentiate between modules with root panels and child panels visually. Merely the behavior at runtime differs basically.
For most use cases, the use of the wizard for opening child panels (dialogs) or modules with root panels is sufficient. In conjunction with the panel topology you can offer the user a very efficient user interface. Moreover, you can handle almost each operation case through the handling of windows/dialogs through the integrated Script languageCONTROL. For more information, see chapter Handling of Modules, Panels and Child Panels or the online help under Types of Functions > panel.ctl.
