[Arquivo!] Qualquer pergunta de novato, de modo a não desorganizar o fórum. Profissionais, não passem por ela. Não poderia ir a lugar algum sem você - 2. - página 486

Novo comentário
 
abolk:

mostrar como você lê a variável global_trailing_SP


No momento, para a posição principal, o valor do trailing é calculado pela ATR desta forma:

void Trailing_Stop_by_ATR_SP(int Timeframe,int Period_ATR_SP,double Multiply_SP,int digits_symbol,int Magic)
{  
   double High_1     = NormalizeDouble(iHigh(Symbol(),Timeframe,1),Digits);
   double Low_1      = NormalizeDouble(iLow(Symbol(),Timeframe,1),Digits);
   double atr        = iATR(Symbol(),Timeframe,Period_ATR_SP,1);
   double new_trail  = Low_1 + NormalizeDouble(((Multiply_SP*atr)*digits_symbol)*Point,Digits);
    
   for(int count = OrdersTotal()-1; count >= 0; count--)
      {  OrderSelect(count,SELECT_BY_POS,MODE_TRADES);
      
         if (OrderType() == OP_SELL && OrderMagicNumber() == Magic)
            {  double Op_Price = NormalizeDouble(OrderOpenPrice(),Digits);
               double Stp_Loss = NormalizeDouble(OrderStopLoss(),Digits);
               
               if (new_trail < Stp_Loss && new_trail > High_1)
                  {  
                     OrderModify(OrderTicket(),Op_Price,new_trail,0,0,White);
                  }
            }
      }
}
Mas não há nenhum problema com isso, pois a posição principal é a de ficar atrás, sem erros. O problema é atribuir o mesmo valor a outra(s) posição(ões).
 
FOReignEXchange:

Portanto, não entendo. A ordem pendente existe no momento da modificação da ordem principal?

Se existir, então a modificação da ordem principal e a modificação da ordem pendente estão no mesmo bloco. E se a ordem principal for modificada, o pendente deve fazer o mesmo, se essa for a sua idéia.

Outra coisa é que nossa idéia não funciona. Isso significa um erro no estado. Tente fazer tudo da mesma forma que na condição de modificação da ordem principal, como eu mostrei acima. Parece-me que o erro está na lógica. Não me surpreende. Aqui tudo é muito complicado. Deveria ser mais simples.


É bem possível que você deva simplificá-lo. Isto é inexperiência).

No momento, é assim, para a posição principal em uma função separada. Então, se houver ordens pendentes ou outras posições com outras majors, seus valores são verificados em relação à parada da posição principal. E se eles forem diferentes, o valor do principal é tomado.

 
FOReignEXchange:

Não me surpreende. É um pouco complicado para você. Você deve manter as coisas simples.

Eu mantive tudo simples. O problema parece ter desaparecido até agora. Combinei a trilha para todas as posições. Farei modificações de ordens pendentes em uma função separada. Obrigado.)))
 
tol64:
Tornei tudo mais simples. O problema parece ter desaparecido até agora. Obrigado.)))


O quê, a pausa é modificável ou algo assim? :)

A caligrafia tem que mudar. Quanto mais clara for a caligrafia, menos erros serão cometidos. Tente não amontoar tudo em uma pilha, o mínimo possível de variáveis e outras coisas desnecessárias. Sempre comece a colocar os suportes em uma nova linha para tornar os blocos claramente visíveis.

 
FOReignEXchange:

O quê, a armadilha foi modificada ou algo assim?


Sim, na função acima, ATR trailing, excluí a verificação Magic e acrescentei uma pausa:

if (OrderType() == OP_SELL || OrderType() == OP_SELLSTOP)
 
FOReignEXchange:


A caligrafia tem que ser mudada. Quanto mais clara for a caligrafia, menos erros serão cometidos. Tente não amontoar tudo em uma pilha, com o mínimo possível de variáveis e coisas desnecessárias. Sempre escreva suportes em uma nova linha para tornar os blocos claramente visíveis.

Obrigado pelas dicas. Eu gravo o melhor deles em meus neurônios)).
 
tol64:


Sim, na função acima, ATR trailing, excluí a verificação Magic e acrescentei as pausas:


Sim. Isso mesmo, eu estava prestes a dizer Magik. Veja. Não há necessidade de variáveis desnecessárias. Vejo vocês mais tarde.
 
FOReignEXchange:

Sim. É verdade, eu ia dizer Magik. Veja. Não há necessidade de variáveis desnecessárias. Vejo vocês mais tarde.


Essa é uma idéia sábia: "Não há necessidade de variáveis desnecessárias".
Não há necessidade de um magik... por que verificar o pedido de um magik?
Se você modificar um pedido de outro EA, tudo bem.
Você deve excluir o mágico como uma classe em geral - seus desenvolvedores perderam seu tempo - e nós fomos submetidos a lavagem cerebral por todos os tipos de mágicos.

p.s. E para o dançarino, o que está no caminho é melhor aparado.

 
abolk:


idéia sábia - "sem necessidade de variáveis extras"
e "sem necessidade de um mágico" - por que verificar o pedido de um mágico?
modificar um pedido de outro assessor - nada demais.
excluir o mágico como uma classe


)))) Não, eu acho que seria melhor deixar o mágico. Você deve simplesmente deixar as ordens pendentes.

Para ser mais exato, devemos deixar os mágicos que são necessários. Se utilizarmos vários Expert Advisors em diferentes gráficos, devemos também incluir símbolos na verificação. Mas eu ainda não cheguei a este ponto. ))

 

Nunca uso mágicos de forma alguma. Embora às vezes existam alguns itens de cada vez. Eu uso bilhetes. É muito mais fácil de verificar através da OrderSelect. E a função OrderSend se torna mais clara. Bem, cada um é o mestre de sua própria caligrafia. Pessoalmente, nunca tive nenhum problema sem os mágicos.

O bilhete nunca vai a lugar algum. É conveniente com ele.

1...479480481482483484485486487488489490491492493...537
Novo comentário
Razão: