Inspector doesn't show macro values of template instances after file→open

[anjohnson]

I'm using VisualDCT's hierarchical (template) features, passing macros down into template instances. When I open the inspector on a template instance in a parent diagram that I have loaded from a file, the Value column is never populated with the macro values saved for that instance, the cells just appear empty. They can be set and they are displayed properly on the diagram though. It is necessary to save the parent diagram to a file and reload it for the values to disappear though, so this is probably related to the save/load operation rather than the inspector itself.

Don't know if these are related or not, but there are other problems with ports and macros when saving and reloading a file containing template instances (some of these may require multiple instances of the same template to trigger, not sure but that's what I'm doing):

• Ports don't always reload with their graphic connectors in the same order as when they were saved, which causes the diagram to change if they are wired up (the wires do stay with the right connection though).
• Macros lose their wired connections if the macro is wired to another macro being passed in from the super-parent diagram. The instance does load the macro's value correctly, but the wire disappears after reloading the diagram from the file.

[ralphlange]

I have never used VisualDCT's hierarchical (template) features, and I do not know anyone (else) that does.
These features require changes to EPICS Base, don't they?
@msekoranja: How mature are these parts?

[msekoranja]

Description: http://www.aps.anl.gov/epics/extensions/vdct/2.6.1274/DES-VisualDCT_EPICS_Databases_Hierarchy_Support.html

The syntax is not supported by EPICS base, however VDCT (and the command-line tool) are there to convert hierarchical DB to a standard "flat" DB format.

[anjohnson]

I have been working on (playing with?) a branch of Base that adds Perl code to flatten hierarchical databases as part of the build process, but it isn't complete yet. The flattening process that I would like to support is quite complex, more so than is currently implemented in either my script or in VDCT, and actually requires making multiple macro- and port-value substitution passes through the hierarchy to implement it properly.

For example, last week I wanted to be able to create a template that defines a series of ports as constant values to implement a lookup table, then in the parent diagram use the value of one of those ports whose port name is made up using a macro that was passed in from the parent diagram. Here's a brief example of the relevant parts:

devDg535_parms.vdb:

template("DG535 Parameter Table") {
  port(ai_readDelay_a, "3")
  port(ai_readDelay_b, "21")
}

devDg535_ch.vdb:

template("DG535 Channel") {}
expand("devDg535_parms.vdb", DG535) {}
record(ai, "$(device):$(ch)DelayAI")
  field(DTYP, "dg535")
  field(INP, "#L$(L) A$(A) @$(DG535.ai_readDelay_$(ch))") # This doesn't work
}

devDg535.vdb:

template("DG535 Device") {}
expand("devDg535_ch.vdb", dg535_a) {
  macro(device, "$(device)")
  macro(L, "$(L)")
  macro(A, "$(A)")
  macro(ch, "a")
}
expand("devDg535_ch.vdb", dg535_b) {
  macro(device, "$(device)")
  macro(L, "$(L)")
  macro(A, "$(A)")
  macro(ch, "b")
}

etc. There are actually 4 channels on each DG535 device, each of which has 5 parameter values that I wanted to look up (a full implementation could have had 15). This template approach would have let me hide all those parameter values in that single sub-diagram, whereas to implement it now I have to pass down the parameters for each channel as macros from the top-level devDg535.vdb diagram, making each channel template instance rather large because of the number of macros it requires.

To be clear, this issue is not a request to implement the above in VDCT, I'm just explaining how I got to this point and where I might be going in the future.