>What I want is only 1 xygraph control that gets
the PV name from the 'group' control selected..
I like what you have in mind.
An actual Tabbed Container with 40 tabs, each containing an
XYGraph would be a great waste of CPU and memory because all
the tab's content is to some degree active, connected to PVs
Better to have 40 selectors which somehow update just one
What you can try is having that XYGraph in an embedded
display (Linking Container).
That embedded display somehow receives one of the 40 sets
of PVs as macros.
has a related example. Two buttons that write some local
'select' PV, and embedded display (Linking Container) which
reacts to that PV by updating the macros of the embedded
display with a script:
# Attached to to embedded display (Linking Container)
# pvs PV 0, 1, ... that selects which macros to use
from org.csstudio.opibuilder.scriptUtil import PVUtil
value = PVUtil.getLong(pvs)
macros = widget.getPropertyValue("macros").getCopy()
if value == 0:
That example has 2 cases instead of 40, and it only sets one
"PV" macro, but you can easily add more.
Note that after changing the macros, it needs to change the
"opi_file" to trigger an update of the embedded display
For what it's worth, the Display Builder, i.e. the update to
BOY, has a "Navigation Tabs" widget.
It looks like the Tab widget (which is also available),
but each Tab is configured with the name of a display to embed
At runtime, when you select a tab it loads the display file
and macros for that tab, basically what the switch.zip example
Compared to the original Tab widget, changing tabs takes a
tiny bit longer because it loads the file for that tab,
creates the widgets, connects to PVs etc., but on the other
hand only the content for one tab is active at a time. Other
tabs use zero CPU and memory, which tends to be an overall