Erro nº 1 na modificação de ordens - página 6

Novo comentário
 
tara:
Como você votou?
Hoje estava frio (+15), então saí com minhas roupas vestidas. E eu não picava nada porque não me dizia respeito.
 
Akella ...
 
tara:
Akella...

Não fique arrogante! O que você quer dizer?

 
borilunad:

Todas as verificações são feitas antes do loop, com condições relativas a cada tipo e uma chamada a esta função, que só verifica se há erros em Modify():

Qualquer outra coisa, pergunte, mas estou indo jantar agora. ;)

Boris, obrigado, é claro, pela ajuda. Mas acabou que meu bicho foi enterrado no lugar errado. Estava em outro lugar. Após o envio do pedido pelo mesmo método de envio, houve uma modificação, e então, com o mesmo tique, modificação por outra condição. Assim, quando a ordem foi aberta, houve erros nesse tick. E não houve erros em outros momentos.

Se formos mais longe, a função de verificação de Stop Loss e Freefall + correção de preço ali, se as condições não forem absolutamente observadas, está correta, mas a curva do compilador não quer lidar corretamente com ela por algum motivo. Eu imprimo tudo, tudo fica como deveria, um nível acima de tudo também fica claro. Mas não obteve nenhum resultado. Eu vi essa função em duas partes, e agora tudo funciona.

Claro que não gosto de toda esta curvatura, mas sobreviverei por enquanto...

 
hoz:

Boris, obrigado, é claro, por sua ajuda. Mas, na verdade, descobri que eu tinha o lugar errado para ser enterrado. Estava em outro lugar. Após o envio da ordem no mesmo método de envio, houve uma modificação, e então, no mesmo tick, modificação por outra condição. Assim, quando a ordem foi aberta, houve erros nesse tick. E não houve erros em outros momentos.

Se formos mais longe, a função de verificação de Stop Loss e Freefall + correção de preço ali, se as condições não forem absolutamente observadas, está correta, mas a curva do compilador não quer lidar corretamente com ela por algum motivo. Eu imprimo tudo, tudo fica como deveria, um nível acima de tudo também fica claro. Mas não obteve nenhum resultado. Eu serrei essa função em duas partes, e agora está funcionando.

Claro que não gosto de toda esta curvatura, mas sobreviverei por enquanto...

Seja bem-vindo! Eu também não tenho tudo em ordem! Finalmente terminou outra EA. Eu tentei o dia todo e finalmente só agora é que ele se liga corretamente. Terei novamente algumas surpresas no Real. O principal é persistência, paciência e perseverança!
 
https://forum.mql4.com/ru/65622
 
azfaraon:
https://forum.mql4.com/ru/65622
Aconselho-o a entrar em contato com o próprio professor! Você quer mudar a lógica de seu sistema, e ninguém o fará melhor do que ele, e é improvável que você encontre alguém disposto a mexer no código de outra pessoa, especialmente, muito provavelmente ultrapassado, e para "segurança" por um segurança sem título!
 

Boris, o senão é que sua função não leva em conta uma série de fatores. Por exemplo, se um tradewolf é ou não permitido... etc. Eu tenho tais cordas em minha função de modificação:

   while (IsTradeAllowed() == true)
      {
         if (!IsExpertEnabled() || IsStopped() || li_Cnt > 200)
         {
            CLogs.WriteLog (StringConcatenate ("Error: Trying to send order ", GetNameOP (fi_Type), " | Price: ", DToS (fd_Price), " NOT IsTradeContextBusy"));

            if (!IsExpertEnabled())
            {
               CLogs.WriteLog ("Permit ExpertEnabled !!!");
            }
            return (-1);
         }

Isto é, por exemplo. Portanto, meu ponto é que a brevidade nem sempre é conveniente. Afinal, estes cheques estão presentes na verdadeira torrente, de qualquer forma. Então por que não colocá-los na caixa preta?

e não pensa mais neles? Também é mais fácil assim...

É mais simples somente se você tiver uma plataforma adequada. Em nosso caso, esta não é a melhor opção. Mas é possível encontrar uma espécie de meio termo. Códigos não muito longos, mas também não vazios.

 
hoz:

Boris, o senão é que sua função não leva em conta uma série de fatores. Por exemplo, se um tradewolf é ou não permitido... etc. Eu tenho tais cordas em minha função de modificação:

Isto é, por exemplo. Portanto, meu ponto é que a brevidade nem sempre é conveniente. Afinal, estes cheques estão presentes na verdadeira torrente, de qualquer forma. Então por que não colocá-los na caixa preta?

e não pensa mais neles? Também é mais fácil assim...

É mais simples somente se você tiver uma plataforma adequada. Em nosso caso, esta não é a melhor opção. Mas é possível encontrar uma espécie de meio termo. Códigos não muito longos, mas também não vazios.

Victor, tenho um cheque para resolução comercial antes de abrir uma posição, e também verificar se há Equidade suficiente e muitas outras coisas, mas no início, não nas funções! Então, por que verificar na modificação?
 
borilunad:
Victor, eu tenho um cheque para permitir a negociação antes de abrir uma posição, assim como um cheque para equidade suficiente e muitas outras coisas, mas no início, não na função! Então, por que verificar na modificação?

Boris, é simples.

Em primeiro lugar, neste caso você não esquecerá no futuro, pois este cheque estará sempre presente.

Em segundo lugar, esta verificação requer tão pouco tempo que não dará nenhuma otimização do código e não acelerará o processo. Isto é, ou verificar se "Permitido negociar" e entrar na função, ou entrar e verificar se "Permitido negociar".

Em terceiro lugar, concordo sobre a equidade, ela deve ser implementada separadamente. Eu mandei serrar esta peça. E muitas coisas removidas. Agora a função é curta em geral.

1234567
Novo comentário