You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
How to use RefreshRates() function correctly ?
Also read on forum "ERROR: code=138 - requote".
I have "OrderSend error 138" generated in tester several times per second... is it a requote ? If so, how to fight with it)?
After reading 20 threads about requotes... I finally figured out what my mistake was)
I had a "pseudo" requote. The reason was the entry condition that was triggered and therefore the price was sent to . In reality, the real price was lower or higher than the one announced in . Every time OrderSend tried to open an order, it gave error 138, of course.
The solution was to check before OrderSend if the real price was equal to the price passed by the signal)
What remains to be done is error checking for OrderModify orders, because this might lead to bad consequences - no stop!
I think we don't need check for OrderSend, let it beat its pulse at the price given by the signal) If requotes come, it won't matter - I'll have time to buy or sell. The main thing is that everything works as planned)
After reading 20 threads about requotes... I finally figured out what my mistake was)
I had a "pseudo" requote. The reason was the entry condition which was triggered and therefore the price was passed to OrderSend. And in reality, the real price was lower or higher than the one I had entered in OrderSend. Every time OrderSend tried to open an order, it gave error 138.
The solution was to check before OrderSend the real price, whether it was equal to the price passed by the signal).
It remains to check for errors for OrderModify orders, because this may lead to bad consequences - no stop!
I think there's no need to check OrderSend, let it beat its pulse at the price the signal sets) If requotes come, it won't matter - I'll have time to buy or sell. The main thing is that everything works as planned)
RefreshRates();
useful to do before accessing Ask Bid
If you want to check all Sell or Buy Limit values before the block that calculates stop take and entry price - long range pending orders may not be affected if they are not calculated based on the current price
RefreshRates();
it is useful to do it before accessing Ask Bid
Isn't that what I did... before the Bid
before the block that calculates stop take and entry price - long distance orders might not be affected if they are not calculated using the current price
Isn't that what I did... before turning to Bid
>>Please explain. So in my case it's not needed here, because it's not counting, it's comparing? Am I reading this right?
You did the right thing :-)
It is not a problem there!
It is just that the block where you access prices should preferably be in one place
it is preferable to have this command before applying
You address to the Bid Ask and after calculating all stops you have to enter the market without much delay.
---
add this to the code
in simplified terms
1 - Signal received - set flag for execution.
2refresh() calculate takeaway stops
3-in
4-server rejected
5-decode error
6-signal is still active- execution flag set?
7- go to point 1
and it is necessary to break this cycle
because it can become quite long
but we have to
1-decide on error
2 - try to bang the dealer not as long as the cycle calls for
2.1 for example you could do a count of how many times you bang
2.2 you can do a quantum of time
2.3 MUST keep track of whether you have a signal before issuing commands for execution!
or you might want to cancel it!
...it's just that you should have the block where you access prices preferably in one place
and it's preferable to have this command before you call
you go to the Bid Ask and calculate all stops to enter the market without any delay...
In one place... I don't quite get it... I'm making an indicator for a long time but I can't complete the loop.)
I have it like this:
-The price to enter is defined by functions UpTrend() and DownTrend() that check for the signal
-check (if) for price parity with the price from the signal
-The price to enter and prices are processed by OrderSend
-the stop price is processed in the ModifyPos() function that follows OrderSend
1- Signal received - flag set for execution //the signal check function passes the order setting function
2-refresh() calculate takeoffs //check for consistency with the price - price of the signal (if it is still active)
3-entry //calculation of takeoffs is static in the OrderSend function, stops in the OrderModify function
4-server rejected //if the order is not placed and there is a signal, then re-enter at the price of the signal (if it is still valid)
5-decode the error //you need it for yourself, in case there is a new problem
6-signal is still active - flag to execute ? //condition of price match - price from the signal (if it is still valid).
7-go to step 1 //to step 3
and we have to break this cycle.
it can become quite long //as long as the price==the price of the signal, I don't think so, but it may be frequent)
but we have to
1-determine the error //I think I'll work on it today.
2-try to bang the dealer not as long as it should be //the price==the price of the signal
2.1 for example you can do a counter for how many times you need to go long // have to think about it, check your history in the tester
2.2 you can do it in a quantum of time //may miss the price==the price of the signal (if it's still active)
2.3 You MUST check if there is a signal before you give orders to execute each series!
it might be time to cancel the signal //the signal check function passes the order setting function
Now I don't understand how to correctly implement OrderModify ? Without it I can't set stop... DC limit on opening...
- can get an error of 130 if price changes after opening and it gets closer
-it is possible to get a requote error 138 and the price will go higher and then the stop will not be set at all
-it is possible to get a 138 requote and the price will go lower, which is not critical as the stop will be set later.
So...
The disadvantages of this variant are
-If the price moves below the open price, the stop will never be set
If the price goes below the open price, the stop will never be placed - it will always try to modify the order. Or it won't?
or so...
Disadvantages of this variant
-There will be a lot of errors if the price moves against
For now I'm considering this option on the stop, put it on until it's set up)
But there are errors in lines with ModifyB; ModifyB;
- ';' - variable already defined
- ';' - variable already defined
Another option, but also with errors (
Another option, but also with errors (