Organizando o ciclo do pedido - página 11
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Entretanto, é melhor não fazer isso - tudo deveria estar em seu lugar.
No temporizador EA, tomamos uma lista de acordo com os critérios exigidos e na lista.Total()>xxx fazemos o que queremos.
Acontece que na antiga MQL4, onde não havia temporizador, o problema não tinha solução? Por que se preocupar com o temporizador, quando ele pode ser resolvido em poucas linhas?
Era exatamente para isso que eu estava olhando.
E meu posto
E, qual é o sentido no comércio real de que devemos perseguir continuamente o ciclo das ordens? Mais importante ainda, é uma perda de tempo...
Ter sempre informações atualizadas sobre o ambiente comercial, e não procurar sempre que necessário, mas consultar as listas disponíveis. E como as listas devem estar sempre atualizadas, vale a pena ter o cuidado de mantê-las atualizadas, mas de forma eficiente.
Afinal, se você não tiver listas, terá que procurar informações quando precisar delas. E não apenas uma vez por carrapato. E é aí que todos os freios de carregamento repetitivo do ambiente vão aparecer.
Embora também seja possível otimizar aqui - se desistirmos do controle sobre as mudanças do ambiente e preenchermos as listas somente quando necessário. Mas então você perderia a capacidade da EA de reagir às ações de fechamento/modificação/abertura manual do usuário.
Acontece que na antiga MQL4, onde não havia temporizador, o problema não tinha solução? Por que se preocupar com um temporizador quando ele pode ser resolvido em poucas linhas?
Quando era impossível fazê-lo, tínhamos que pensar como resolvê-lo. Mas agora é possível ;)
Ter sempre informações atualizadas sobre o ambiente comercial, e não ter que procurar sempre que necessário, mas consultar as listas existentes. Como as listas devem estar sempre atualizadas, vale a pena ter o cuidado de mantê-las sempre atualizadas, mas de forma eficiente.
Afinal, se você não tiver listas, terá que procurar informações quando precisar delas. E não apenas uma vez por carrapato. E aqui todas as lentidões aparecerão em repetidos carregamentos de ambiente.
Embora, mesmo aqui, possa ser otimizado - se você se recusar a controlar as mudanças do ambiente e preencher listas somente quando necessário. Mas então, você perderá a capacidade da EA de reagir às ações do usuário no fechamento/modificação/abertura manual.
Essa é a palavra-chave"mas eficaz". E qual é o significado mais profundo de atualizar a lista a cada milissegundo se a lista só pode mudar quando outro tick chegar? E por que não apenas uma vez por carrapato? Um pedido pode ser fechado fora de um tick? A meu ver, mesmo que não haja um tick e a EA envie um comando para abrir/fechar, ou seja, para mudar o ambiente, ou seja, a lista, esta ação causará um tick. Ou se não for, então sem um carrapato causado por outra coisa, a lista não será alterada. Não é assim?
Aqui está a palavra-chave"mas efetivamente". E qual é o sentido tão profundo de atualizar a lista a cada milissegundo, se a lista só pode mudar ao receber o próximo tick? E por que não apenas uma vez por carrapato? Um pedido pode ser fechado fora de um tick? A meu ver, mesmo que não haja um tick e a EA envie um comando para abrir/fechar, ou seja, para mudar o ambiente, ou seja, a lista, esta ação causará um tick. Ou se não for, então sem um carrapato causado por outra coisa, a lista não será alterada. Não é assim?
No testador, eu dirijo o OnTimer(), que cria listas apenas do OnTick(), mas na vida real você não faz diferença...
Mas é necessário um cronômetro não apenas para a criação de listas. Tudo de uma só vez - tudo o que precisamos. Por enquanto. Um perfil adicional mostrará os gargalos.
Essa é a palavra-chave"mas efetivamente". E qual é o significado mais profundo de atualizar a lista a cada milissegundo, se a lista só pode ser alterada com a chegada de outro carrapato? E por que não apenas uma vez por carrapato? Um pedido pode ser fechado fora de um tick? A meu ver, mesmo que não haja um tick e a EA envie um comando para abrir/fechar, ou seja, para mudar o ambiente, ou seja, a lista, esta ação causará um tick. Ou se não for, então sem um carrapato causado por outra coisa, a lista não será alterada. Não é assim?
Há um ponto em força bruta do temporizador se o programa funcionar com muitos símbolos - os carrapatos chegam em momentos diferentes.
Mas não faz sentido procurar "não a sua" lista de pedidos, mas aquela criada pelo terminal, que é a razão dos problemas que a lista é alterada por outra pessoa.
Há um ponto em força bruta do temporizador se o programa funcionar com muitos símbolos - os carrapatos chegam em momentos diferentes.
Mas não faz sentido procurar "não a sua" lista de pedidos, mas a lista criada pelo terminal, que é a razão dos problemas quando a lista é alterada por outra pessoa.
No caso da lista "não sua", há uma quantidade total de pedidos que podem ser armazenados em uma variável estática e executar o loop para enumerar o ambiente à medida que ele muda. Mas nem todo milissegundo...
Caso a lista não seja "sua", há um número total de pedidos que podem ser armazenados em uma variável estática e rodar um loop para executar novamente o ambiente à medida que ele muda. Mas nem todo milissegundo...
Você não pode pegar o acionamento de uma ordem pendente desta maneira.
Não é possível apanhar o gatilho de uma ordem pendente desta forma.
Portanto, não estamos falando de pegar pulgas, ou seja, uma ordem pendente, estamos falando de tentar todas as ordens a cada milissegundo.
Portanto, não se trata de pegar pulgas, ou seja, ordens pendentes, trata-se de passar por todas as ordens a cada milissegundo.
- Para que você precisa de uma frigideira?
- Por exemplo, para fritar ovos.
- Não se trata de ovos mexidos, mas sim da frigideira.