No, Zorro does nothing with volume. So what you do with the value returned by marketVol is completely up to the broker plugin and to your script. The "volume per minute" is a suggestion what _could_ be returned.
Damn. This is troubling. I see MT4/5 does not even support volume data at all:
marketVal: Not supported.
marketVol: Not supported in historical data, tick frequency in live data.
http://zorro-project.com/manual/en/mt4plugin.htmWhy is that? MT4 does know about volume.
Wouldn't it be natural to pass that in marketVol instead of 'tick frequency', whatever that is?
https://docs.mql4.com/predefined/volumeSo you have marketVal and marketVol as additional, optional values. Any particular reason why 2?
Are 2 the maximum of optional data values someone ever needs?
This idea of a function called
marketVol(int) (assuming "Vol" stands for "Volume") could return something other than volume looks like a design flaw. If the broker sends some other data for it, then ideally the user should not require to add checks in his code prior calling marketVol to make sure it is indeed a volume value. marketVol should just return 0, indicating that it has no known volume data from that current data source.
To accommodate arbitrary data values you would expect a
marketVal(int index, int offset) function, where the given index selects the optional data values at their natural position. I would even consider to add a new data structure such as:
typedef struct T4X
{
DATE time;
float fHigh, fLow;
float fOpen, fClose;
float* fVal;
} T4X;
Where the pointer of fVal would point to an additional series of arrays. This would allow for true arbitrary optional data values.
I would suggest to mark
marketVol(int) and
marketVal(int) as deprecated and add new functions
marketSpread(int),
marketVolume(int) and
marketVal(int index, int offset).
marketSpread(int) and
marketVolume(int) should return spread and volume if the system knows that the values are indeed what they promise, for example by the broker plugin, or t6 data files, otherwise 0.
Now to the next problem: How to correctly collect the optional asset data for a given bar. The current design gives the user no possibility to collect correctly. So
marketVol(int) and
marketVal(int) are useless in many cases. The proposed
marketSpread(int) and
marketVolume(int) functions could automatically solve this problem, because since they know what the value is, they can internally collect the value correctly. For example while priceHigh(int offset) collects the highest value within the bar,
marketVolume(int) would collect the sum of all values within the bar. Sounds fair?
Now, what about
marketVal(int index, int offset)? It probably needs a third parameter taking an optional function pointer to tell how data should be collected. So
marketVal(int index, int offset, void* collectFunction), where the collect function could look something like
var collect(var collectedValue, var nextValue)
{
return collectedValue + nextValue;
}
var collect(var collectedValue, var nextValue)
{
return max(collectedValue, nextValue);
}
The collect function gets called by zorro for each data point within the given bar. This would enable the user to specify how zorro should collect the optional asset data. void* collectFunction should be a proper function pointer if Lite-C supports it.
Anyone agrees with this?