>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 etc.
Better to have 40 selectors which somehow update just one XYGraph.
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 (Linking Container).
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 and macros.
At runtime, when you select a tab it loads the display file and macros for that tab, basically what the switch.zip example does.
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 win.