Organizando o ciclo do pedido
Continuando o tema de lançamento das bibliotecas MQL5 sob MT4
#property strict // https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic #include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh void OnStart() { double Y[] = {1, 2}; GraphPlot(Y); }
Muitas vezes no testador, se o controle deslizante de velocidade estiver ajustado para 31, é lento, se estiver ajustado para 32, o teste chega a sua conclusão com super velocidade.
Eu saio dele inserindo um atraso através do contador no código:
input int gDelay = 10000; // Счетчик для задержки, off=0 void OnTick() { int delayCount = 0; while(delayCount < gDelay) ++delayCount; }
O atraso via entrada pode ser ajustado dependendo da velocidade da EA e da potência do processador.
Na velocidade 32, agora posso ir para os pontos de interesse a uma velocidade que me convém.
Abaixo abordaremos um assunto que diz respeito não apenas ao MT4, mas também ao MT5 com outras plataformas. Mas a lógica será escrita em MQL4 para facilitar a percepção, portanto, neste ramo.
Na maioria das vezes a espinha dorsal (a carne de qualquer pedido) de modificação/eliminação de pedidos se resume à seguinte lógica
// Самый распространенный костяк логики модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration());
Agora, a abordagem é rara, mas muito mais correta
// Редкий, но правильный костяк модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration())) { i = OrdersTotal(); // Хотя бы так // А лучше так // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно) }
Após o envio de uma ordem comercial, o ambiente comercial muda, portanto é aconselhável executar toda a lógica comercial do TS a partir do zero imediatamente após a resposta do servidor comercial.
Agora a abordagem é rara, mas muito mais correta
Esta variante se prende à modificação da última ordem da lista a qualquer erro, e o Expert Advisor que tem mais de 1 ordem "perde a visão" de todas as outras.
Minha receita: fazer loop em todas as suas ordens, processar cada uma delas (atualizando as informações de mercado antes de processá-las, se necessário), e no próximo tick, a próxima abordagem. Em alguns casos, a próxima abordagem (chamada OnTick) pode ser feita imediatamente após o loop atual ter terminado, caso tenha havido erros nele.
Esta opção faz um loop na modificação da última ordem da lista quando há algum erro, e uma EA com mais de 1 ordem "perde a visão" de todas as outras.
Não haverá looping devido a esta condição
if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))
Minha receita: faça um loop em todos os seus pedidos, processe cada um deles (atualize as informações de mercado antes de processá-los, se necessário) e no próximo tick, a próxima abordagem. Em alguns casos, a próxima abordagem (chamada OnTick) pode ser feita logo após o término do loop atual, se houver erros nele.
Então, mais erros de pedidos comerciais podem ser vistos no registro do terminal.
Não haverá looping devido a esta condição
Sim, errado, leia-o como !OrderModify.
Se a modificação for bem sucedida, o processamento também não poderá ser repetido desde o início da lista, pois neste caso uma ordem também será modificada (por exemplo, puxada para trás do preço), e as outras poderão ficar sem supervisão por um longo tempo.
Minha receita ainda é válida.
Eu não recebi essa.
Se a modificação for bem sucedida, o processamento também não poderá ser repetido desde o início da lista, pois neste caso uma ordem também será modificada (por exemplo, puxando para trás do preço), e as outras poderão ficar sem supervisão por um longo tempo.
Há algo de errado nesta lógica desde o início. Devemos fazer uma escolha consciente: é melhor ter uma ordem real ou muitas ordens irrelevantes.
Minha prescrição ainda é válida.
Eu não recebi esta.
Deixe a OrderModify funcionar por 5 segundos. Durante sua execução, deixe uma ordem de limite parcial ser executada várias vezes no servidor de negociação, gerando uma dúzia de negociações.
Algo nesta lógica está errado desde o início. Você tem que fazer uma escolha consciente: melhor uma ordem real ou muitas outras irrelevantes.
Um pedido não pode estar em níveis diferentes ao mesmo tempo. Ou devemos ter um EA diferente para cada nível? Esta é uma solução questionável para a grande maioria das estratégias.
Como um caso especial, várias posições (conquistadas por tendência com várias entradas) e uma parada para eles. Puxar o SL de apenas um comércio, ou modificar todos eles? Em um movimento brusco com o mesmo retrocesso brusco subseqüente, a opção de modificar apenas uma ordem perderá muito (e não chegaremos ao resto, pois cada nova chamada para a OnTick modificará a primeira ordem da lista).
Deixe OrderModify funcionar por 5 segundos. Durante sua execução, vamos supor que uma ordem de limite parcial foi executada várias vezes no servidor comercial, tendo gerado uma dúzia de negócios.
Suponha que sim. Processaremos todas as ordens que foram (e devem ser) executadas, e passaremos às novas ordens no próximo tick ou diretamente após o primeiro ciclo.
Caso contrário, sempre corremos o risco de trabalhar com uma - última - parte executada de uma última encomenda. Talvez a menor parte. Deixando uma grande encomenda pendurada ali sem supervisão.
Um pedido não pode estar em níveis diferentes ao mesmo tempo. Ou devemos ter um EA diferente para cada nível? Esta é uma solução questionável para a grande maioria das estratégias.
Como um caso especial, várias posições (conquistadas por tendência com várias entradas) e uma parada para eles. Puxar o SL de apenas um comércio, ou modificar todos eles? Se tivermos um movimento brusco com um recuo subsequente igualmente brusco, a opção de modificar apenas uma ordem perderia muito (e não alcançaremos o resto, pois cada nova chamada para a OnTick modificará a primeira ordem da lista).
Não entendo porque OnTick modificaria apenas um pedido? Todos eles serão modificados.
Digamos. Processaremos todos os pedidos que foram (e devem ser) processados e passaremos aos novos pedidos no próximo tick ou imediatamente após o primeiro ciclo.
Caso contrário, arriscaremos sempre a trabalhar com uma - a última - parte executada de uma última encomenda. Talvez a menor parte. Deixando uma grande encomenda pendurada ali sem supervisão.
Chamo a atenção para a palavra "espinha dorsal". A carne na forma de seleção de prioridade de lote ou outra coisa sempre pode ser construída. A lógica central, por outro lado, permanece a mesma: após uma ordem comercial bem sucedida, executar toda a lógica comercial a partir do zero.
Não entendo por que a OnTick modificará apenas um pedido? Tudo será modificado.
Como o preço se moverá, e a cada nova chamada para a OnTick, a condição para uma nova modificação do mesmo, primeiro na lista, a ordem será cumprida. Especialmente se a modificação durar 5 segundos ;)
Note a palavra "espinha dorsal". A carne na forma de seleção de prioridade de lote ou outra coisa sempre pode ser adicionada. A lógica central, por outro lado, permanece a mesma: após uma ordem comercial bem sucedida, executar toda a lógica comercial a partir do zero.
Tal "espinha dorsal" quebraria a lógica de uma EA trabalhando com mais de uma ordem.
Para que serve se não der nenhuma vantagem aos sistemas com uma ordem e estragar as outras?
Classificar por volume e/ou distância do preço antes de trabalhar com pedidos é uma boa solução. Mas não devemos assumir que todos que copiam o código do fórum o implementarão.
Nesse sentido, meu código é mais seguro.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso