The base class for the calculation of technical indicators. Indicators are managed by and added to an instance of BG.charts.Data
To display the values calculated by an indicator, the generated buffers have to be referenced by an instance of BG.charts.Layer that is added to a BG.charts.Chart.
Indicators have to provide information about their values, and the preferred type of layer via the BG.charts.Indicator:getLayers method.
must be called after willUpdateOptions
once all actions that might potentially changed values of any options are done
IMPORTANT: methods must be called in balance; e.g. for each call to willUpdateOptions
, you must call didUpdateOptions
exactly once.
returns a flat representation of all available config options in the form of a key-value-object optionally only values that are not read-only can be returned
IMPORTANT: this method will always convert I18NStrings to strings, so for displaying strings in a UI use individual calls to BG.charts.Object:get instead
Optional
readWriteOnly: booleandefault: true
Optional
modifiedOnly: booleandefault: true
Optional
nonEphemeralOnly: booleandefault: true
returns the categorization of the objects options can be used for displaying a more structured user interface
called to calculate all values from startIndex to endIndex
pointer to an api object
index of the first value to calculate
index of the last value to calculate
called when underlying data changes
pointer to an api object
called to initialize the indicator
this is only called once, immediately after the constructor
it is required because in contrast to the constructor
events emitted from this method can be handled
E.g. if the indicator needs to asynchronously load data
it can trigger the loading
event from here
called to restart the indicator by default this automatically calls onEnd onStart onData indicators can however implement their own logic, e.g. to reuse buffers
pointer to an api object
called to register and initialize the indicator
pointer to an api object
called to shutdown and deinitialize the indicator
pointer to an api object
life cycle method; called when the object should stop normal operation if objects have any pending subscriptions/requests, they should all be stopped here
the object is also responsible for clearing the loading flag from it's state if it is currently active failing to do so will trigger a fatal error
object might be started again afterwards (start) or destroyed (destroy) this is not known yet at this point
called after start or restart
will set validate and then set the specified option(s) to the provided value(s) after validation
NOTE: if multiple options are used, will return false if at least one value is not valid values are applied individually however, so one option might be set even if the value for another is invalid
by default EventEmitters will print a warning if more than 10 listeners are added for a particular event. This is a useful default which helps finding memory leaks. Obviously not all Emitters should be limited to 10. This function allows that limit to be increased. Set to zero for unlimited.
set number of usable inputs; must be at least 1 calling this method resets previously required buffers
the optional second parameter can be used to provide name(s) for the input option(s) Note: number of provided names needs to be identical to requested number of inputs
set options to be considered "parameters"
parameters show up in the name of the indicator, e.g. in the legend entry or a UI e.g. as follows: type(parameter1, parameter2)
the optional second parameter can be used to specify a custom name to be used instead of the type
ordered list of parameters to be shown in the name
Optional
name: stringoption name to be used instead of type
when using custom getters/setters (via _get/_set) in options, the values of options can change
without .set being called - or there might not even be a setter for readonly options;
for example, if the getter simply returns the value of a member variable
this variable could be modified directly.
In this case, events such as optionChanged
would not be fired, and listeners would not be informed about the change.
To account for such cases, the methods willUpdateOptions
and didUpdateOptions
should be called directly BEFORE and AFTER
actions that might potentially change values of options.
the correct events will then automatically be triggered when calling didUpdateOptions
.
if the options that could change are known, they can be supplied via the optional parameter. This provides a small performance gain in most situations.
IMPORTANT: methods must be called in balance; e.g. for each call to willUpdateOptions
, you must call didUpdateOptions
exactly once.
Optional
options: string | string[]Static
getMethod for plugins to describe which other plugins they want to replace
Static
guardStatic
listenerStatic
set
*Example of an options definition with the most common attributes: