Class BiDiBLightManager

    • Method Detail

      • createNewLight

        public Light createNewLight​(java.lang.String systemName,
                                    java.lang.String userName)
        Create a new Light based on the system name. Assumes calling method has checked that a Light with this system name does not already exist.
        Specified by:
        createNewLight in class AbstractLightManager
        systemName - the system name to use for this light
        userName - the user name to use for this light
        null if the system name is not in a valid format.
      • startLoad

        public void startLoad()
        This function is invoked before an XML load is started. We defer initialization of the newly created turnouts until finishLoad because the feedback type might be changing as we are parsing the XML.
      • finishLoad

        public void finishLoad()
        This function is invoked after the XML load is complete and all Sensors are instantiated and their type is read in. We use this hook to finalize the construction of the objects whose instantiation was deferred until the feedback type was known.
      • createSystemName

        public java.lang.String createSystemName​(@Nonnull
                                                 java.lang.String curAddress,
                                                 java.lang.String prefix)
                                          throws JmriException
        Create a System Name from hardware address and system letter prefix. AbstractManager performs no validation.
        Specified by:
        createSystemName in interface LightManager
        createSystemName in class AbstractManager<Light>
        curAddress - hardware address, no system prefix or type letter.
        prefix - - just system prefix, not including Type Letter.
        full system name with system prefix, type letter and hardware address.
        JmriException - if unable to create a system name.
      • validateSystemNameFormat

        public java.lang.String validateSystemNameFormat​(java.lang.String name,
                                                         java.util.Locale locale)
        Validate the format of name, returning it unchanged if valid.

        Although further restrictions may be added by system-specific implementations, at a minimum, the implementation must consider a name that does not start with the System Name prefix for this manager to be invalid, and must consider a name that is the same as the System Name prefix to be invalid.

        Overriding implementations may rely on Manager.validSystemNameFormat(java.lang.String), however they must provide an actionable message in the thrown exception if that method does not return Manager.NameValidity.VALID. When overriding implementations of this method rely on validSystemNameFormat(), implementations of that method must not throw an exception, log an error, or otherwise disrupt the user.

        name - the system name to validate
        locale - the locale for a localized exception; this is needed for the JMRI web server, which supports multiple locales
        the unchanged value of the name parameter
      • validSystemNameConfig

        public boolean validSystemNameConfig​(java.lang.String systemName)
        Validate system name for configuration.
        systemName - system name to validate
        'true' if system name has a valid meaning in current configuration, else returns 'false'. For now, this method always returns 'true'; it is needed for the Abstract Light class.
      • allowMultipleAdditions

        public boolean allowMultipleAdditions​(java.lang.String systemName)
        Determine if it is possible to add a range of lights in numerical order eg 11 thru 18, primarily used to enable/disable the Add range checkbox in the Add Light pane.
        systemName - system name to check for (not used so far)
        true if multiple additions are possible. For now, this is always the case.
      • configAll

        public void configAll()
        Request config from all LC ports. The resulting config messages are processed by the Message Listeners of the Light and Sensor instances.