borilunad: Victor, you, Renat, in general rightly pointed out, Alexey showed the necessary last check, and earlier check all the necessary checks for each parameter with all the nuances to avoid ambiguity of meaning and without missing any condition!
What good would that do? Because I'm resetting _LastError value in each function. It's not like it's constantly hanging in memory...
hoz: What's the use of it? Because I reset _LastError in every function. It's not like it's constantly hanging in memory...
Sorry, you're a victim of your functions and checks! Output the info to the chart for interest, and print the error checks only after the trading functions!
Then it gets the market info. If the modification is in the tester... then... I do the test proposed by Alexei, and... if the modification is unsuccessful, then... write a log and prints in the log...
In general, we can see that there are no errors between ResetLastError()... There's nothing to be wrong there.
Log:
020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Вошли в функцию
020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: До проверки на FREEZELEVEL и STOPLEVEL тикета № 2020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Тикет № 2; OOP = 1.34048; SL = 1.34125; TP = 1.33362020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::CheckLevelsBLOCK: Вошли в функцию
020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::CheckLevelsBLOCK: Тикет № 2; fd_NewOpenPrice = 1.34048; fd_NewSL = 1.34125; fd_NewTP = 1.33362020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::CheckLevelsBLOCK: fi_Type > 2 = true020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::CheckLevelsBLOCK: Тикет № 2; fd_NewOpenPrice = 1.34048; fd_NewSL = 1.34125; fd_NewTP = 1.33362020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::CheckLevelsBLOCK: Вышли из функции
020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: После проверки на FREEZELEVEL и STOPLEVEL тикета № 2020:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: PositionsManipulations::fOrderModify: Тикет № 2; OOP = 1.34048; SL = 1.34125; TP = 1.33362220:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: modify #2 sell limit 0.10 EURUSD at 1.34048 sl: 1.34125 tp: 1.33362 ok
320:24:082013.08.2600:00 Kevin Martens_Moi_Myrei EURUSD,M15: OrderModify error 1
I hear you. It didn't help. Here's a piece of code from my modification method:
You can clearly see that the error value is being reset.
Then it gets the market info. If the modification is in the tester... then... ...then I run the test proposed by Alexei, and... if the modification is unsuccessful... write a log and prints in the log...
In general, we can see that there are no errors between ResetLastError()... There's nothing to be wrong there.
Log:
You need to log the previous OOP, SL and TP values before the change to see if they are the same as the new ones, then the cause of error #1 will also be clearer.
Let me explain. The modification takes place in method fOrderModify(). At the input of this method fOrderModify(), the current values of the order parameters and the new planned values are printed at the beginning of the body. You can see it:
The Bid is always lower than SellLimit, so the line if(New_OOP < Bid) will never be true... ...respectively, the modification is implemented without hindrance.
Why don't you create an error array as well? It is written in black and white in the documentation that the _LastError variable stores the number of the last error. And it is reset by ResetLastError() function. If there are no more errors between calls of _LastError, _LastError stores the value of the last error. There were no more errors in my code. Well, that's not the question.
You are absolutely wrong. The last error is well reset in many important functions. It works so in WinAPI too.
That is why you should save the error code into a local variable right after it occurs and not try to use it after clearing this system variable ten times in a lot of your intermediate functions.
Victor, you, Renat, in general rightly pointed out, Alexey showed the necessary last check, and earlier check all the necessary checks for each parameter with all the nuances to avoid ambiguity of meaning and without missing any condition!
What's the use of it? Because I reset _LastError in every function. It's not like it's constantly hanging in memory...
still need to check that if none of the 3 parameters has changed, then OrderModify doesn't need to be touched either.
I hear you. It didn't help. Here's a piece of code from my modification method:
We can clearly see that the error value is reset.Then it gets the market info. If the modification is in the tester... then... I do the test proposed by Alexei, and... if the modification is unsuccessful, then... write a log and prints in the log...
In general, we can see that there are no errors between ResetLastError()... There's nothing to be wrong there.
Log:
I hear you. It didn't help. Here's a piece of code from my modification method:
You can clearly see that the error value is being reset.Then it gets the market info. If the modification is in the tester... then... ...then I run the test proposed by Alexei, and... if the modification is unsuccessful... write a log and prints in the log...
In general, we can see that there are no errors between ResetLastError()... There's nothing to be wrong there.
Log:
That's how it is...
In the Expert Advisor, I call the class method like this:
Here's the piece of the class we're interested in:
Here's the log piece we want:
Let me explain. The modification takes place in method fOrderModify(). At the input of this method fOrderModify(), the current values of the order parameters and the new planned values are printed at the beginning of the body. You can see it:
This piece is in the log:
You can see that the parameters are all different. There should be no problems.That's how it is...
In the Expert Advisor, I call the class method like this:
Here's the piece of the class we're interested in:
Here's the log piece we want:
I don't understand what the Bid has to do with the Bid, if the order is pending?
The Bid is always lower than SellLimit, so the line if(New_OOP < Bid) will never be true... ...respectively, the modification is implemented without hindrance.
Why don't you create an error array as well? It is written in black and white in the documentation that the _LastError variable stores the number of the last error. And it is reset by ResetLastError() function. If there are no more errors between calls of _LastError, _LastError stores the value of the last error. There were no more errors in my code. Well, that's not the question.
You are absolutely wrong. The last error is well reset in many important functions. It works so in WinAPI too.
That is why you should save the error code into a local variable right after it occurs and not try to use it after clearing this system variable ten times in a lot of your intermediate functions.
Sorry, SellLimit requires dist:
not if (New_OOP < Bid) continue; butif (New_OOP-dist*Point < Bid) continue;
How do I get rid of this fucking error? I'm sick of it. I'm checking every input parameter of the function. For me, at the moment, it's like this:
That is, if the parameter hasn't been changed, there's no need to change it. I haven't done that before, but I decided to...
Then the parameters are passed to the order modification method like this:
Nw output in the log:
So, the journal notifies us, like modification: OK, but then... an error. None of the parameters has changed.
The order is pending. So we may change open, stop and take price. And this, as I understand it, did not contradict the documentation.
Who has encountered something like this? How to solve it?