Qualquer pergunta de novato, de modo a não desorganizar o fórum. Profissionais, não passem por aqui. Em nenhum lugar sem você - 6. - página 901
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
Os cálculos desnecessários (irrelevantes para o problema) foram removidos. As impressoras foram adicionadas ao código especificamente para mostrar o problema. Apesar da comparação do símbolo do pedido com o símbolo no qual a EA está aberta, a EA pode mostrar o seguinte (a partir do gráfico Ozi pegue os dados do pedido em euros, por exemplo, como neste caso):
Este não poderia ser o caso, não há como o Ask no canguru ser mais alto do que qualquer preço aberto no Eurodólar em 2015...
E todas as verificações para a ordem selecionada são melhor feitas após a seleção, com uma cláusula if() separada.
Este não poderia ser o caso, não há como o Ask on the Kangaroo ser mais alto que qualquer preço de abertura do Eurodollar em 2015...
E todas as verificações para a ordem selecionada devem ser feitas após a seleção, com uma cláusula if() separada.
É verdade, não poderia. É por isso que deu ordens Bid<openPrice em 1.11262.
Em outras palavras, você sugere verificar a presença de um pedido usando o if(OrderSelect()), e depois no embutido se já compararmos o símbolo do gráfico com o símbolo do pedido, preço aberto, etc.?
É verdade, não poderia. É por isso que ele deu uma ordem Bid<openPrice para a UE em 1.11262.
Em outras palavras, você sugere verificar a existência de um pedido usando o if(OrderSelect()), e depois comparar o símbolo do gráfico com o símbolo do pedido, preço aberto, etc., no if embutido?
Dançar ao redor não vai ajudar.
Não há diferença para escrever a seleção do pedido e verificar se há símbolo e mágico em uma linha ou dividi-los em 3 linhas diferentes. De acordo com as mudanças nas condições de verificação das novas construções são verificadas em etapas, ou seja, se a primeira condição não for cumprida, as seguintes não serão verificadas. É o mesmo que as 3 linhas. A primeira condição é cumprida e a segunda é verificada. E somente se a segunda condição também for cumprida é que procederemos à verificação da terceira.
O problema é provavelmente que há uma chamada de uma função do usuário na parte apagada do código onde outra ordem é selecionada.
Se tivesse havido alguma menção de trabalhar com encomendas, essa teria sido a primeira coisa em que reparei. Mas há apenas cálculos, não uma única função do usuário utilizada. Não está claro o que exatamente causa uma ordem para ser selecionada de outro par. É por isso que estou tão intrigado com o "ambiente de software" mencionado na documentação e já refiz o código como o evillive sugeriu e estou pronto para dançar com pandeiros. A próxima perversão será uma comparação forçada com a proposta de compra do par necessário através do marketinfo.
UPD.: Problema resolvido. Na verdade, encontrou uma função aninhada que utiliza seu próprio OrderSelect. Obrigado pela idéia, AlexeyVik.
Criei um EA (não para trabalhar, apenas para praticar)
Se eu definir os dois parâmetros na função IF, se eu os definir um por um, tudo funcionará bem, aqui está o código (Além disso, como posso ter certeza de que se eu já tiver uma ordem de compra aberta a próxima ordem de compra não será aberta, mesmo se todas as condições combinarem)?
Criei um EA (não para trabalhar, apenas para praticar)
Se eu colocar os dois um por um, funciona bem, ou seja, o código (e se eu já tiver uma ordem de compra aberta, como faço para que uma ordem de compra não abra a próxima, mesmo que todas as condições estejam corretas?)
Não que seja a fonte de todos os problemas, mas puramente de interesse acadêmico: por que simultaneamente OnInit(), OnDeinit() e depois de repente começar()?
E quanto à pergunta, não é altamente recomendável que tal comparação Ask == MA, muito raramente se realiza na história. Então, o que significa tal expressão PC-->MA?
Quanto à permissão para uma compra, fazemos um loop em todas as posições de mercado e as comparamos com os critérios especificados - símbolo, tipo, número mágico, e aumentamos o contador em um se for encontrado o procurado. Em seguida, quando necessário, este contador é verificado.
É assim que as coisas são:
Não que seja a fonte de todos os problemas, mas puramente por interesse acadêmico: por que simultaneamente OnInit(), OnDeinit() e depois de repente começar()?
E quanto à pergunta, não é recomendável que tal comparação Ask == MA, ela muito raramente se concretiza na história. Então, o que significa esta expressão PC-->MA?
Quanto à permissão para uma compra, fazemos um loop em todas as posições de mercado e as comparamos com os critérios especificados - símbolo, tipo, número mágico, e aumentamos o contador em um se for encontrado o procurado. Em seguida, olhamos para o balcão, quando necessário.
start() mudou o contador por "hábito" )
Por que Ask === MA é um evento raro? O preço atual do lance raramente toca a linha Moving Average?
O PC-->MA está no meu caso se o preço anterior de fechamento for maior que a linha de Média Móvel (não descobri outra maneira).
Então, quando eu habilito a função IF um a um com Ask == MA e depois PC-->MA funciona bem, mas quando eu os combino, não funciona!
Não que seja a fonte de todos os problemas, mas puramente por interesse acadêmico: por que simultaneamente OnInit(), OnDeinit() e depois de repente começar()?
E quanto à pergunta, não é recomendável que tal comparação Ask === MA, muito raramente se realiza na história. Então, o que significa esta expressão PC-->MA?
Quanto à permissão para uma compra, fazemos um loop em todas as posições de mercado e as comparamos com os critérios especificados - símbolo, tipo, número mágico, e aumentamos o contador em um se for encontrado o procurado. Em seguida, quando necessário, este contador é verificado.
É assim que é:
Meu entendimento é que PC-- > MA é o mesmo que PC-1 > MA.