Trade Management - page 2

New comment
 

interesting - but still confusing for an amateur programmer like me. Can one of you please tell me how to change this simple piece of code for a trailing stop to eliminate these irritating intermitent Error 1s.

double MySLGap = ..... // whatever trailing stop gap you want that should be valid
if (BID - OrderOpenPrice()  > MySLGap || OrderStopLoss()  < BID - MySLGap)
 {
   Res = OrderModify(OrderTicket(), OrderOpenPrice(), BID - MySLGap, 0, 0, Blue);
   if (Res < 1)
   .........
}
 
BigAl:

interesting - but still confusing for an amateur programmer like me. Can one of you please tell me how to change this simple piece of code for a trailing stop to eliminate these irritating intermitent Error 1s.


Wrong Topic......

You have already opened a topic named Error 1 for this problem.....

Ask there for answers...

 
For yet another example of avoiding Error#1. Using WHRoeder's Format. Here: https://forum.mql4.com/45482.
 

I prefer readable code as well....

I don't yet understand what WHRoeder's "flat" is doing. Please give me a bit of time to do my homework on it.

I'm also somewhat stunned that in MQL4, I don’t seem to be able to code a reliable IF-statement using doubles. In other High Level programming languages, I was able to move (for example) a 10 character field into a 5 character field, chopping off the last 5 characters.

In MQL4, I don't seem to be able to truly delimit a field defined as double to the 4th position after the coma, using NormalizeDouble. So I never know if I'm comparing "apples" with apples".

Or is there an other option????

Thanks for all the comments and I'll come back with my findings over the weekend.

 
redhat:

I prefer readable code as well....

I don't yet understand what WHRoeder's "flat" is doing. Please give me a bit of time to do my homework on it.

I'm also somewhat stunned that in MQL4, I don’t seem to be able to code a reliable IF-statement using doubles. In other High Level programming languages, I was able to move (for example) a 10 character field into a 5 character field, chopping off the last 5 characters.

In MQL4, I don't seem to be able to truly delimit a field defined as double to the 4th position after the coma, using NormalizeDouble. So I never know if I'm comparing "apples" with apples".

Or is there an other option????

Thanks for all the comments and I'll come back with my findings over the weekend.

It's Raptor's flat . . ;-) NormalizeDouble does work . . . and if you NormalizeDouble everything in sight it will work . . . it just seems that NormalizeDouble does it's normalizing a little differently to the way other things in mql4 do . . . so sometimes you have issues.

My "Flat" is effectively doing my own version of NormalizeDouble. Using what WHRoeder suggested is probably superior, but for some of my code it would impact heavily on it's readability.

 
Sorry I wanted to say RaptorUK's "flat".
 

Ok, I had a go at Raptor's "flat" function. For me, it didn't deliver the desired results.

Finally I decided to go for a old fashioned solution, setting a Error flag, in case the IF-statement using the normalized fields fucks up and subsequently ends up producing a Error 1.

However this is crude programming.

MQL4.com has outstanding work to do here........... !

Normalizing a value to the 4th digit after the coma means 1.1234 and NOT 1.123400000000....0001. Everitime and not just "working well in 99%".


Thanks for all the explanations, suggestions and support. I learned something here.


NormalizeDouble(OrderOpenPrice_TM,4);
NormalizeDouble(OrderStopLoss_TM,4);
 
redhat:

Ok, I had a go at Raptor's "flat" function. For me, it didn't deliver the desired results.

Thanks for the feedback :-) one question, did you apply it to both sides for the test ?
 
redhat:
Normalizing a value to the 4th digit after the coma means 1.1234 and NOT 1.123400000000....0001. Everitime and not just "working well in 99%".

0.1 can not be exactly represented in a double, either you get 0.099999999999 or 0.10000000000001. NormalizeDouble must chose one or the other. That's why NormalizeDouble(Bid,Digit) != Bid sometimes. Raptor's Flat is just another implimentation - doesn't change the fundimental.

Don't use NormalizeDouble. Ever.

 
WHRoeder:

Raptor's Flat is just another implimentation - doesn't change the fundimental.

I think this version should address the issue . . . not tested yet.

int Flat(double ValueToFlatten)
   {
   int Power = MathPow(10, Digits);
   
   return(MathFloor(Power * (ValueToFlatten + (1/(Power*10)))) );
   
   }
123
New comment
Reason: