market and use it whereever you would use Prices of the original market.
When graphing, you can either graph that market instead of the original
market via Prices, or you can not show the original market via
--type=none and only graph indicators depending on the alternative
market. Of course, you cannot use volumes from the alternative market,
so you need to graph with --novolume.
I do not think any change to the data sources is required unless you
need the volume of the other market, or you need to use that other
market in various timeframes beyond just the timeframe of the primary
market.
Th.
Robert A. Schmied wrote:
both GT/Prices.pm and GT/Indicators/Prices.pm will need modification
if you want
the gt indicators to be able to access this 'other data' in the prices
object.
naturally whatever database interface module you are using may need
alteration
or configuration as well.
however none of the apps that utilize GT/Graphics/DataSource methods
to create and
render graphic objects will handle this 'other data' unless you also
alter them
(the apps) and possibly also implement suitable additional datasource
module(s)
to support this 'other data'. GT/Graphics/DataSource/Prices.pm and
Volume.pm
might serve as models for any additional module(s) that might be needed.
can we ask the type and the nature of this 'other data'? there may be
better
alternatives to loading up the prices object with additional data
especially
if this data isn't of a market dynamic sort.