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
Digamos que o preço sobe 600 ponto do OrderOpenprice(), = StartTraillingStop (200) + 8(xai)*50
o código está aqui :
mas o código fará todo o xai de 0 a 8, digamos que o código está em xai = 4; esta condição é verdadeira ?
if ( ( ( OrderClosePrice() - OrderOpenPrice() ) / Figure ) >= ( StartTrailingStop + ( CummulativeValue * xai ) ) )
sim, então o SL será fixado em : StartTraillinStop (200) + 4(xai)*50 ( descendo do anterior )
então xai 5, o SL será fixado em : StartTraillinStop (200) + 5(xai)*50
e assim por diante, de modo que não é possível colocar uma pausa uma vez que o SL esteja definido;
juniorlcq Seu código é muito mais fácil de ler agora que você o reformatou. Eu o reformatei um pouco mais para torná-lo menor para postar, eu tenho destacado possíveis problemas. Estou pensando que você pode ter um problema "duplo == duplo calculado" que está impedindo que seu código execute algumas das trilhas. Você já leu o tópico sobre preço de latas != preço ?
Estou mais desconfiado do 2º e 4º, pois são cálculos mais complicados.
Coloque Print() declarações após esses cálculos para ver se eles realmente fazem == ou não.
O erro conhecido como erro de ponto flutuante pode fazê-los != mesmo quando parece que eles deveriam ser ==.
== é realmente apenas 100% seguro para usar com inteiros, então você pode mudar o == para <= ou >= como um teste.
Também como uma nota lateral: Seu código seria muito mais eficiente se você chamasse OrderOpenPrice(), OrderStopLoss(), OrderClosePrice() uma vez no início de seu loop OrderSelect() e atribuísse seus valores aos vars locais para usar durante todo o resto do código. Os vars locais são de acesso muito mais rápido do que as chamadas de função, portanto você deve evitar fazer chamadas de função repetidas para o mesmo resultado... Como regra geral, quanto mais escrita cor-de-rosa você tiver em seu código, mais lento será o desempenho da EA.
Eu entendo, eu não posso fazer funcionar, este pode funcionar com a compra de encomenda, SL estão gioingando para baixo como explicado :
Ohhhhhhh Eu não sabia disso. Obrigado WHRoeder :) .
Isso significa, portanto, que ,
digamos OrderTotal() == 3 , com a contagem regressiva para loop for ( int x = ( OrderTotal() - 1 ) ; x >= 0 ; x-- ) x economizará o 1º valor como 2 , então continuará o laço de 2 em diante sem passar por OrderTotal() novamente ??
juniorlcq Seu código é muito mais fácil de ler agora que você o reformatou. Eu o reformatei um pouco mais para torná-lo menor para postar, eu tenho destacado possíveis problemas. Estou pensando que você pode ter um problema "duplo == duplo calculado" que está impedindo que seu código execute algumas das trilhas. Você já leu o tópico sobre preço de latas != preço ?
Estou mais desconfiado do 2º e 4º, pois são cálculos mais complicados.
Coloque as declarações Print() após esses cálculos para ver se eles realmente funcionam == ou não.
O erro conhecido como erro de ponto flutuante pode fazê-los != mesmo quando parece que eles deveriam ser ==.
== é realmente apenas 100% seguro para usar com inteiros, então você pode mudar o == para <= ou >= como um teste.
Não, eu nunca li essa linha antes. Apenas li .
O que você sugeriu fazer parece lógico . Pensando bem, às vezes traçando linhas no MT4 sobre as propriedades do preço não mostra realmente o preço de 5 dígitos, em vez disso, às vezes mostra algo mais do que isso .
Mas aqui está um dos meus negócios flutuantes sobre o da conta anterior , eu o imprimi para ver como era o duplo com um simples código de impressão . Estranho MQL4 Acho que @.@ ?
Eu ainda estou pensando como devo modificar o duplo === dupla parte .....
Também como uma nota lateral: Seu código seria muito mais eficiente se você chamasse OrderOpenPrice(), OrderStopLoss(), OrderClosePrice() uma vez no início de seu loop OrderSelect() e atribuísse seus valores aos vars locais para usar durante todo o resto do código. Os vars locais são de acesso muito mais rápido do que as chamadas de função, portanto você deve evitar fazer chamadas de função repetidas para o mesmo resultado... Como regra geral, quanto mais escrita cor-de-rosa você tiver em seu código, mais lento será o desempenho da EA.
Ohhh Eu não sabia que haveria uma enorme diferença na velocidade de execução , obrigado pelo guia SDC . Será modificado de acordo com seu guia após a parada da trilha ter começado a funcionar .
Tente substituir o último bloco de código por esta versão debug. Verifique meu código que eu não compilei.
Isso poderia revelar algo, você poderia fazer algo semelhante com as outras == condições também.
Tente substituir o último bloco de código por esta versão de depuração. Você poderia fazer algo semelhante com o xa
Isso poderia revelar algo, você poderia fazer algo semelhante com as outras === condições também.
Yup os problemas surgem , é o " duplo == duplo problema calculado " . Obrigado por apontar o problema SDC .
Obrigado ffoorr por também apontar o mesmo problema antes, mas eu não o editei da maneira correta e achei que não era o problema.
Mas tenho uma pergunta a fazer, para o 2º e 3º, se no 2º para loop, é melhor colocar uma declaração "entre" ? Como OrderStopLoss() >= x + 1 && x - 1 ?? Ou devo apenas usar >= ou <= ??
Espero que WHR não leia isto, ele terá um ataque, mas vou lhe dizer para tentar NormalizeDouble() .... deve fazer com que essas condições sejam iguais quando supostamente devem ser iguais. Não deveria ser necessário fazê-lo também ao lado OrderStopLoss(), mas se ainda assim não vier igual quando deveria tentar fazê-lo a ambos os lados da condição....