MQL4 how to get if a price hits an object?
How to get if a price hits an object? Lets say, the object is a pitchfork, or trendline, manually drawn. I guess, it should start this way:
if(Bid==?)
Not a bad guess
Let's go through the story step by step.
A price: . . . which one ?
{ Ask, Bid } - while most of Technical Analyses are derived from a Bid-based perspective, one must have experienced that certain XTO-events are related to Ask price levels.
For the sake of simplicity, let's keep the Bid as the only price to work with, while the framework could be extended to have the complete PriceDOMAIN duality under the hood.
A TimeFrame: . . . which one ?
Sounds strange? Well, not so surprising, MetaTrader Terminal 4 graphics does not allow one to place GUI-objects arbitrarily. While this need not be realised from the very start, one will fail if trying to place a GUI-object onto an exact TimeDOMAIN coordinate. The PriceDOMAIN coordinates are not so restricted, but additional surprises appear if one of the GUI-object definition points fall into far or near future, but the respective Market-session administratively closes ( a FRI/MON-gap, a midnight-gap, DE.30/DAX post-Market/pre-Market-gap etc. ) before the real-time reaches the "future" point in time. Such objects become distorted if not completely jumped-off-the screen.
Besides this the concept of TimeFrames introduces another question -- does the condition if(Bid....) that we are just to assemble -- hold and yields the very same result in D1, H4, H1, M5 and M1? While this seems to be simply decided in PriceDOMAIN ( and it is not in practice, another bad surprise is waiting behind the corner ) it is quite sure, that TimeDOMAIN coordinates of when a condition constellation was met do and will differ, depending on TimeFrame, on which the GUI-object is placed and challenged with the algorithm.
Simply put, while GUI-objects are painted "continuous", they are not. Their internal representation in MQL4 ecosystem is discrete, so one shall rather forget all the algebra of linear and quadratic objects.
The best would be to imagine a GUI-object as an ordered set of [x-TimeDOMAIN, y-PriceDOMAIN] coordinates -- yes, an ordered set of points, where the x ( surprising or not ) is visually the most misleading - the middle of the bar representation is not the "middle" of the real-flow of time, but the administrative Market wall-clock - the time of the beginning of the Bar.
How to handle all these glitches and guess the value(s)?
To have at least some help from MQL4 side, there are a few utility functions for this:
int ObjectGetShiftByValue( string anObjectNAME, // ...
double aTargetPriceLEVEL // a price to reach
)
plus
double ObjectGetValueByShift( string anObjectNAME, // guess what
int aShiftInTimeDOMAIN // bar index
)
One will have a lot of troubles saved by this pair of handy functions, but still will have to implement a carefull handling of weekend/market-gaps ( the bars-space that is "now" visible, but will "disappear" in some near future and dare one to have GUI-objects with a definition point "forgotten" right out there ... ).
Last, but not least ... A danger of == ... not only in if(Bid...)
( An Orwellish "We are all equal, but some of us are more equal... " )
Guess everyone, who has spent some time with Custom Indicator construction, has also met the dark side of IEEE-float numerical (im)precision. Smoothing and deep convolution computations introduce this phenomenon sooner than later and a first-aid ( double-precision float ) does not eradicate the principal loss of numerical precision these representations of non-integer values simply have to suffer from.
This said, one shall rather knowingly work with imprecise numbers and replace binary strict equality tests ( == ), that are failing to yield fair answers on noisy un-precise numbers, and rather use this glitch:
#define EQUALITY_TOLERANCE 0.000005
if ( EQUALITY_TOLERANCE > MathAbs( Bid - aTargetPRICE ) )
{ // EQUAL
}
else
{
}
Certainly, the same logic applies to PriceDOMAIN cross-testing and other derived { >= | > | < | <= | != } conditions.
