Invalid price x.xxxx0000 for OrderClose() function

 

I've only just started in the forex market a few weeks ago and have written quite a few EAs in the last few weeks.


Have had a particular error which occasionally appears with one of my EAs.


I have the same EA performing on 4 different symbols under the same MIG demo account.


I've noticed that sometimes when orders are being closed I get an error message that suggests that x.xxxx0000 is an invalid price for the OrderClose() function.


Notes:

- I do use the IsTradeAllowed() function

- I have been using the MarketInfo() function to retrieve the price and then normalizing to the correct number of digits (4 or 2 - not 8 as above in the error message)

- In my latest version, I avoid using this function and instead use the Ask and Bid prices associated with the symbol directly - I'm not yet sure that this fixes the problem

- Strangely - it happens even for symbols where there are no existing orders (ie. my OrderClose() function should not be called since the OrdersTotal() function should produce no orders)

- It doesn't seem to have a material impact - all my orders seem to get closed ok


I'm thinking it may be to do with me doing maths on the result of the OrdersTotal() function in order to set up a loop to close each order.


Any ideas?



Many thanks,

CB

 

"..correct number of digits.." depends if you have sub pip pricing broker. it is then 5 or 3.

whats wrong with invalid price? the docs state that terminal and/or EA is working with old data - consider how RefreshRates() can be used. The docs give answers as to when should us it...

do you normalize ALL expressions? in mql, those digits to the left of the 2/4 or 3/5 digits can and will cause you double issues and what you think are sending is not what server wants.

do you use test Print()'s all over the place?

do you use DoubleToStr(dval,8)?

Digits is ok but it will NOT show what's in the double to the right of those 2/4 or 3/5 'Digits'...

search the forum - loads of stuff on this - you are walking paths countless others have trodden and posted about too ;)

 
fbj:

"..correct number of digits.." depends if you have sub pip pricing broker. it is then 5 or 3.

whats wrong with invalid price? the docs state that terminal and/or EA is working with old data - consider how RefreshRates() can be used. The docs give answers as to when should us it...

do you normalize ALL expressions? in mql, those digits to the left of the 2/4 or 3/5 digits can and will cause you double issues and what you think are sending is not what server wants.

do you use test Print()'s all over the place?

do you use DoubleToStr(dval,8)?

Digits is ok but it will NOT show what's in the double to the right of those 2/4 or 3/5 'Digits'...

search the forum - loads of stuff on this - you are walking paths countless others have trodden and posted about too ;)


"depends if you have sub pip pricing broker. it is then 5 or 3".

I'm using MIG - I believe 4/2 is what they want.


"whats wrong with invalid price? the docs state that terminal and/or EA is working with old data - consider how RefreshRates() can be used. The docs give answers as to when should us it..."

I've moved the price acquisition close to the OrderClose() function but will look at how RefreshRates() can be used. The thing is that teh OrderClose() function shouldn't even be executed in many cases when I get this error.


"do you normalize ALL expressions? in mql, those digits to the left of the 2/4 or 3/5 digits can and will cause you double issues and what you think are sending is not what server wants".

No. I had been using the MarketInfo() function to get a price as a double and then using NormalizeDouble() to truncate it to 2 or 4 places. I had been thinking of just using the Symbol's Ask and Bid variables directly in the OrderClose() function. Is this too simplistic?


"do you use test Print()'s all over the place"?

Damn right I do!! Worked as an assembly programmer 25 years ago and then wrote Cobol for quite some time. Where would we be without the old "display clause".


"do you use DoubleToStr(dval,8)?"

I have never used any function to convert a double to a string.


"Digits is ok but it will NOT show what's in the double to the right of those 2/4 or 3/5 'Digits'..."

I'll need to look for a full explanation on this. I'm obviously missing something about normalization.


"search the forum - loads of stuff on this - you are walking paths countless others have trodden and posted about too ;)"

Will do. On the plus side I did do most of the hard work over the last few weeks and produced working EAs BEFORE bothering you.  ;-)


Thanks again.

 
cloudbreaker:

"depends if you have sub pip pricing broker. it is then 5 or 3".

I'm using MIG - I believe 4/2 is what they want.


"whats wrong with invalid price? the docs state that terminal and/or EA is working with old data - consider how RefreshRates() can be used. The docs give answers as to when should us it..."

I've moved the price acquisition close to the OrderClose() function but will look at how RefreshRates() can be used. The thing is that teh OrderClose() function shouldn't even be executed in many cases when I get this error.


"do you normalize ALL expressions? in mql, those digits to the left of the 2/4 or 3/5 digits can and will cause you double issues and what you think are sending is not what server wants".

No. I had been using the MarketInfo() function to get a price as a double and then using NormalizeDouble() to truncate it to 2 or 4 places. I had been thinking of just using the Symbol's Ask and Bid variables directly in the OrderClose() function. Is this too simplistic?


"do you use test Print()'s all over the place"?

Damn right I do!! Worked as an assembly programmer 25 years ago and then wrote Cobol for quite some time. Where would we be without the old "display clause".


"do you use DoubleToStr(dval,8)?"

I have never used any function to convert a double to a string.


"Digits is ok but it will NOT show what's in the double to the right of those 2/4 or 3/5 'Digits'..."

I'll need to look for a full explanation on this. I'm obviously missing something about normalization.


"search the forum - loads of stuff on this - you are walking paths countless others have trodden and posted about too ;)"

Will do. On the plus side I did do most of the hard work over the last few weeks and produced working EAs BEFORE bothering you.  ;-)


Thanks again.

Found my problem fbj.

Was actually nothing to do with normalization or freshness of data.

My own silly fault - I'd been expecting that OrdersTotal() returned the number of orders in the context of the chart my EA was attached to rather than in the context of the account.

Therefore, I was trying to close an order in another symbol.

I have fixed this by checking the equality of OrderSymbol() with Symbol() once I've performed the OrderSelect();

I feel silly.

 

great!!!

silly? cmon... that's called learning, yes?

you might want to consider magic numbers - vip subject.

congrats on finding your issue ;)

 
fbj:

great!!!

silly? cmon... that's called learning, yes?

you might want to consider magic numbers - vip subject.

congrats on finding your issue ;)


Ta.

I thought about magic numbers but had decided that I was happy enough for now not to use.

The basis for this decision was that I would only at any one time have 1 open trade and it was a binary situation - either the trade is present or it is not.

Given my recent discovery, I can see how magic numbers would help.

However, given that I can determine the symbol context for an order, its still a binary situation. 

Reason: