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
É isso, a solução é simples: introduzimos outro cheque para mudar a história, assim nada será perdido e funcionará 100%.
Isto pode até ser usado como um OnTrade() incompleto
Acho que não sou esperto o suficiente).
Como posso aplicar isto?
Há apenas um problema e é extremamente raro, encontrou-o hoje pela primeira vez em alguns anos, pode ter sido antes, apenas não o notou
Eu estava falando do cálculo da soma do hash - como você pode adicionar um nome de caractere ao valor da soma do hash - calcular os valores dos códigos das letras que compõem o nome do caractere.
É isso, a solução é simples: introduza outra verificação de mudança de história, assim nada será perdido e funcionará 100%.
Aqui está um trecho do meu artigo nº 3:
-------
Vamos nos concentrar mais na quantidade de haxixe como parte da estrutura.
Vamos considerar um bilhete. Adicionar/remover uma ordem pendente irá alterar a quantidade total de ticks na conta, acionando uma ordem pendente não irá alterar a quantidade total de ticks na conta.Não basta saber o número de ordens e posições para poder determinar com precisão o que mudou na conta - uma ordem pendente pode ser excluída, e neste caso o número total de ordens e posições na conta será alterado. Mas... Uma ordem pendente pode acionar e se tornar uma posição. Neste caso, a quantidade total de ordens e posições não mudaria (para contas de hedge e MQL4) - o número de posições aumentou, mas o número de ordens diminuiu, portanto a quantidade total ainda é a mesma. Isto não funciona para nós.
Vamos olhar para o volume total. Você colocou ou excluiu um pedido pendente - o valor total na conta mudou; nós abrimos ou fechamos, ou mudamos a posição - o valor total na conta mudou. Parece ser adequado, mas mais uma vez, ativar uma ordem pendente não irá alterar o volume total.
Portanto, vamos ver mais uma propriedade de posição - tempo de sua mudança em milissegundos: abrir uma nova posição mudará o tempo total de mudança de posição, fechamento parcial mudará o tempo de mudança de posição, adicionar volume a uma conta de compensação mudará o tempo total de mudança de posição.Qual destes métodos é adequado para determinar a localização precisa das mudanças na conta? Bilhete + hora da mudança de posição. Vamos verificar:
Aqui, porém, eu não adicionei um símbolo à soma do hash - não houve precedentes para isso. Mas eu tenho-o funcionando em conjunto com o histórico de cheques. Portanto - deve funcionar sem erros. No entanto, vou verificar isso algum dia.
A solução é simples: introduza outra verificação de mudança de história, assim nada será perdido e funcionará 100%.
E sim, vai. Se o número de pedidos abertos não mudar, então o número no histórico mudará. (Não me importo com ordens pendentes - não as uso) E não teremos que passar o dia inteiro para pegar apenas um evento.
E se o usuário recebeu uma mensagem de texto e decidiu exibir o histórico no terminal em vez de todo ele apenas no último mês, será uma verificação adicional com a tentativa de todos os pedidos, o que não é fatal.
Parece ser uma boa solução. E sem referência a nada além do que temos, que é uma conta comercial e um terminal.
Aqui está um extrato do meu artigo nº 3:
-------
Vamos elaborar sobre a quantidade de hash como parte da estrutura.
Considere um bilhete. Adicionar/remover uma ordem pendente irá alterar a quantidade total de bilhetes na conta, acionando uma ordem pendente não irá alterar a quantidade total de bilhetes na conta.Não basta saber a quantidade de ordens e posições que mudaram na conta para poder determinar com precisão esta mudança - uma ordem pendente pode ser apagada e, neste caso, a quantidade total de ordens e posições na conta será alterada. Mas... Uma ordem pendente pode acionar e se tornar uma posição. Neste caso, a quantidade total de ordens e posições não mudaria (para contas de hedge e MQL4) - o número de posições aumentou, mas o número de ordens diminuiu, portanto a quantidade total permaneceu a mesma. Isto não funciona para nós.
Considere o volume total. Você fez ou excluiu um pedido pendente - volume total da conta mudou, abriu, fechou ou mudou de posição - volume total da conta mudou. Parece ser adequado, mas mais uma vez, ativar uma ordem pendente não irá alterar o volume total.
Portanto, vamos ver mais uma propriedade de posição - tempo de sua mudança em milissegundos: abrir uma nova posição mudará o tempo total de mudança de posição, fechamento parcial mudará o tempo de mudança de posição, adicionar volume a uma conta de compensação mudará o tempo total de mudança de posição.Qual destes métodos é adequado para determinar a localização precisa das alterações na conta? Bilhete + hora da mudança de posição. Vamos verificar:
Aqui, porém, eu não adicionei um símbolo à soma do hash - não houve precedentes para isso. Mas eu tenho-o funcionando em conjunto com o histórico de cheques. Portanto - deve funcionar sem erros. No entanto, vou verificar isso algum dia.
Solução gorda, ainda não há necessidade de tal variante.
Obrigado!
Decisão gorda, ainda não há necessidade dessa opção.
Obrigado!
"Negrito" porque não foi feito para uma solução local, mas como parte de um substituto completo para o OnTradeXXXX. Há mais trabalho com a história.
E esta é uma grande vantagem - temos dados prontos para a busca e classificação de quaisquer ordens e posições no programa (não precisamos buscar ordens e posições novamente para atender às necessidades do programa - tudo já está nas listas). Outra vantagem é que o programa sabe qual ordem originou a posição na MQL4, o que não pode ser feito nas versões mencionadas acima.
Repito, a biblioteca é feita para facilitar as coisas para aqueles que têm muito tempo e dinheiro para fazer tudo sozinhos. Eu não insisto em nada, é claro :)
E assim é. Se o número de pedidos em aberto não mudar, o número na história mudará.(Não me importo com pedidos pendentes - não os uso) E você não tem que incomodar sua avó com os pedidos durante todo o dia para pegar apenas um evento.
E se o usuário recebeu uma mensagem de texto e decidiu exibir o histórico no terminal em vez de todo ele apenas no último mês, será uma verificação adicional com a tentativa de todos os pedidos, o que não é fatal.
Parece ser uma boa solução. Se você tem uma conta e um terminal comercial, você pode usar apenas o que você tem sem estar vinculado a nada.
Para não passar o dia inteiro, você pode verificar apenas quando as condições que podem levar a uma mudança, abertura, fechamento de uma posição, ou seja, o foco em alcançar os preços que o Expert Advisor utiliza para abrir, TP, SL. Bem, isso depende da lógica do Expert Advisor, você sabe o que é mais barato.
Para evitar passar o dia inteiro, você pode verificar somente quando as condições que podem levar a uma mudança, abertura, fechamento de uma posição tiverem sido cumpridas, ou seja, para se concentrar em atingir os preços que o Expert Advisor usa para abrir, TP, SL. Bem, sim, depende da lógica do Expert Advisor, você sabe o que é mais barato.
Uma EA (em um computador, em um continente) opera. O outro (em outro computador, em outro continente) trata de suas funções. Uma solução já foi encontrada.
Ficaria grato se você pudesse fornecer algum exemplo reproduzível (sem pesquisar o histórico comercial).
Aqui está o que surgiu (embora fora de tópico aqui, mas pedido aqui).
Cortar para viver. Sem compatibilidade MT4 (é claro), sem manipulação de erros, etc.
O comércio é primitivo, abre-se BUY, fecha-se em SL/TP. O único ponto é demonstrar a OnTradeTransaction() versus "sondagem no servidor".
Para mim foram necessárias 2,34s vs 3,06s para passar no prazo determinado. A diferença é pequena devido à baixa carga nas funções do servidor (apenas uma posição, sem verificação de magik e símbolo). Na EA real, a diferença será muito maior. A diferença será ligeiramente compensada pelo cálculo dos sinais e pela adição de trailing stops, mas eles não precisam ser feitos em cada tick. Meu ATR é calculado em M1, mas por 6 horas (ou seja, há espaço para ampliar o TF). E o trailing e o Breakeven é calculado em H3. Tudo depende da estratégia.
Vocês estão desesperadamente atrasados!
Estes eventos têm sido garantidos há muito tempo!
Suponha que um evento tenha ocorrido na OnTradeTransaction() após o qual alguma ação deve ser executada, mas um erro ocorreu na primeira tentativa de executar essa ação. O que fazer? Obviamente, deve ser repetido, e para isto é necessário salvar em algum lugar dados sobre a necessidade de repetir estas ações - muito provavelmente, estes dados são salvos nas variáveis globais habituais do Expert Advisor ou em funções estáticas. E de repente tive que reiniciar o terminal... os dados desapareceram.
E quando você analisa a situação atual e a história - nada vai a lugar algum.