Inheritance diagram for SctData.ConfigurationVariable:
Public Member Functions | |
boolean | equals (Object o) |
String | getVariableName () |
String | getStrategyDescription () |
String | getClassName () |
void | write (OStream s, ObjectManager o) throws java.io.IOException |
Static Public Member Functions | |
ConfigurationVariable | read (IStream in, ObjectManager o) throws java.io.IOException |
Protected Attributes | |
short | repVal |
Package Functions | |
ConfigurationVariable (String variableName, String description) | |
Private Attributes | |
String | variableName |
String | description |
Sub-classes represent the particular (logical) variables and the different ways of setting them (e.g. ThresholdVariable represents the logical variable threshold and mVThresholdVariable represents setting the threshold in mV, fCThresholdVariable represents setting it in fC). The sub-classes are intended to be singletons (as they are really strategies and flyweights).
There are lots of methods here, but the basic concept is that there is some underlying 'actual' value. This is either the setting of the appropriate variable in ABCDModule. For instance it could be a DAC setting. The logical value is some manipulation of that - for instance it could be the DAC setting in mV (rather than raw bits) or in fC is there is some calibration information that allows one to be converted to another.
This cocnept certainly has meaning for chip variables and may have meaning for others. This class should be refactored as and when this becomes apparent.
The idea is that this should allow transparent and simple analysis of e.g. a thershold scan done in mV or fC. For the moment these methods aren't used by anything, so I've commented them out
Definition at line 32 of file ConfigurationVariable.java.