That's unfortunately not our's to decide. Only prices are delivered by all brokers, any other data is up to the broker. If they deliver tick frequency instead of volume, marketVol returns the tick frequency. If they deliver spread, marketVal returns the spread. If they deliver nothing, the functions return 0. Different function names or bigger structs won't help.
For this reason, it makes no sense to guarantee a certain volume format. The only requirement is that marketVol returns at least some proxy of volume. Since almost all volume based indicators only use volume changes and not absolute volume, they will work. How useful such indicators are with a MT4 connection where volume is normally the tick frequency, is a different question.
I don't see how this blocks a proper implementation of spread/volume/arbitrary asset data. In the case of MT4/MT5 the documentation clearly states that we have access to a volume value. We also have access to spread. Yet Zorro only delivers a tick frequency. Why?
https://docs.mql4.com/predefined/volumehttps://docs.mql4.com/marketinformation/marketinfoIf the broker decides to send a garbage or no value for volume, and MT4/MT5 hands that garbage/no value to Zorro, why is that a problem Zorro would need to tackle, when the problem is on Broker/MT4 side? You also would not tackle the event if the broker would send garbage for open/high/low/close right? You just take the value as is in the remote platform and hand it over.
Furthermore I don't understand how the current implementation can be any satisfactory, nor do I understand how Andrews proposal fixes it all.
Summary of issues:
- Cannot access/use optional asset data values with BarPeriod > 1 (e.g. when backtesting .t6 data)
- Cannot retrieve volume and spread with MT4/MT5
- Limit of 2 optional asset data values. Cannot use 3 or more
- marketVol/marketVal might not be what they pretend to be / user has to find out / adapt code to different use cases
Different function names or bigger structs won't help.
I did not simply propose different function names or bigger structs. Was my previous text really that non-descriptive?
