First, let's start with the <code>-snippet mis-concept
As seen in the provided <code>-snippet, there is a principal error/mis-concept. While the syntax of the MQL4-code is compiler-phase feasible ( it gets processed into an operational .ex4 runtime-code ), the result is principally wrong.
MQL4 has a lot of enumerated constants, which used to have zero context-of-use checking in the MetaLang.exe compilation phase. ( Yes, had to say "used to have", due to the fact MetaQuotes, Inc., recent move into "hidden"-language modifications has changed a lot of system behaviour, even in the syntax of MQL4, calling it in a rather Orwel-style "New"-MQL4, so one has to pay attention to detail even more under the conditions of moving sands... )
As expressed, an ENUM_CONST alike your attempt to use MODE_PENDING
, has a fair meaning in the language, but that does not guarantee anything but a compile-time substitution of a value of int
. Thus one might state a MODE_HIGH
( btw == 2 ) in any place, where MODE_SMMA
( btw == 2 either ) would have an appropriate context-of-use. These are just symbolic substitutions during the compiler parsing phase.
Second, let's focus on your target
As seen, you would like to somehow operate on a set of knowledge about an overall amount & respective sizes of pending orders, that wait "on the table" before the market turns them active. This is a complex and non-trivial task. The more as FX has no "central" marketplace, to collect the global overall sum of sums.
Speaking about "volume" thereof opens another confusion. Volume
, as implemented in MQL4 is rather a discrete integer value related to a cummulative amount of price changes within the respective bar. Thus, on aNewBarEVENT, the Volume[0] == 1
( the first price-bearing-quote has just arrived & has brought the indication of aNewBarEVENT per se ) and this value is step-wise increasing throughout the live-bar ( [0] ) duration. One may also note, that for bars, where no price-quote appeared "from Market", the MT4 does not show any bar in the graph ( a missing candle ).
So always be carefull on using the word Volume, to assure, one gets it's full context-of-use.
Your intention, as far as detectable from your post, is to obtain an OrderBook LEVEL-2 a.k.a. Depth-Of-Market.
While this is possible, this will require more efforts to assemble, than just a one-liner in MQL4 code.
Third, let's go get the job done
May be, your Broker has an API-service ready for you to collect & process the L2 DoM.
- If not, go and ask them to open it for you.
If not,
- change the Broker to such one, who will.
There are other sources to build & maintaing L2 DoM, but the relevance for your Trade-Execution-Venue is to be verified, as some could make your strategy crippled via a MarketMaking role, once trading against your model.
Your Broker-"local" L2 DoM rulez. Always. Not worth the losses to test the contrary.
If getting ready for this task, be ready to operate on ultra low latency architecture, as sub-milisecond cadencies in L2 DoM evolution dynamics are not uncommon.
Once "on the road", you will soon notice, that MQL4 has a timer resolution above 1 msec.
Thus your computational strategy to query+gather+sanitize+process+publish+use your own local L2 DoM mapping has a trouble right from the start ( not speaking about your principal skew of the map due to end-to-end transport latency ).
( Kindly also do bear in mind, that MQL4 has just a few threads, that are absolutely out of your control. Thus a carefull multi-processing design has to be designed, so as to operate in a non-blocking near-RealTime mode. Having integrated systems alike this, your Project is indeed quite thrilling to achieve the goal, believe me :o)
)
Worth doing the job right nevertheless.