Com o que substituir a OnTradeTransaction() em mql4? - página 3
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
Se precisarmos de uma solução rápida, então eu colocaria todos os bilhetes para CArrayInt e compararia os bilhetes dos pedidos abertos com CArrayInt; o método Search() está lá; se não houver bilhete, paramos de comparar CArrayIntcom balcões de pedidos abertos, reinicializar CArrayInt e escrever todos os bilhetes em CArrayInt novamente e colocar a bandeira descrita globalmente MyOnTradeTransaction - este é um sinal de que a lista de pedidos mudou - o código será bastante compacto
E quando precisamos pegar algo mais do que a perda de pedidos, é quando começamos a dançar com diamantes...
Verificação de ordensTotal() não mostrará, por exemplo, a ativação de uma ordem pendente - o número de ordens permanece o mesmo, assim como os ingressos... E quando precisamos pegar o fato da modificação de pedidos/posições...
Tudo, entretanto, já foi pensado, feito e colocado em domínio público com explicações...
Que vantagens estou negando? Eu tenho apenas uma negação. Quero entender como algo funciona, e se só pode ser compreendido por alguém que não seja minha mente, então não me sinto confortável em usá-lo, e qualquer coisa com a qual não me sinta confortável, eu nego. Eu já lhe disse que você escreve mais cartas do que eu consigo ler para o resto da minha vida. Não descarregue em mim...
Os prós são que nenhum evento pode se perder. Ao contrário da OnTrade() e OnTradeTransaction(). Mas você não acredita que tal evento possa se perder... É por isso que eu digo - a discussão é inútil.
E quando você precisa pegar algo mais do que uma ordem faltante, é aí que começa o pandeiro...
Verificação de pedidosTotal() não mostrará a ativação de um pedido pendente, por exemplo - o número de pedidos é constante, bilhetes, também... E quando precisamos pegar a modificação de uma ordem/posição...
Tudo, porém, já foi pensado, feito e disponibilizado gratuitamente com explicações.
Eu não sugiro analisar as ordensTotal, não é confiável.
Você não será capaz de acompanhar as modificações de pedidos dessa forma, você terá que escrever sua própria classe com base em CArray ou CObj.
Eu sugeri uma solução rápida, não um trabalho fundamental ;)
Os prós são que não podemos perder eventos.
Não estou sugerindo analisar OrdensTotal, não é confiável
modificação de pedidos não pode ser rastreada dessa forma, você precisa escrever sua própria classe com base em CArray ou CObj
Eu sugeri uma solução rápida, não um trabalho fundamental).
eles podem se você pressionar o botão de reset do PC .... não tenho acompanhado os artigos por muito tempo, mas me lembro de perguntar sobre a técnica de salvar o estado de classe para um arquivo caso o terminal seja reinicializado - isso já está implementado?E você também pode jogar um computador da varanda - para perdas confiáveis :) E deixe o rolo esperar abaixo. Então você também pode despejar concreto em cima :)))
Não, não está implementado - não é o principal agora. É quase até o fim - é mais fácil fazer tudo da mesma maneira de uma só vez, em vez de dividi-lo em diferentes faixas de tempo. Para mim.
Não, não implementado - isso não é o principal agora. Está quase no fim - é mais fácil fazer tudo do mesmo tipo de uma só vez, em vez de dividi-lo em faixas de tempo diferentes. Para mim.
OK, vamos esperar
Mas acabei sendo o oposto - já encontrei este problema - não coloquei a capacidade de salvar na estrutura do programa, e comecei a escrever salvando em um arquivo, tudo se tornou muito pesado.... Já encontrei este problema - não coloquei o salvamento em um arquivo na estrutura do programa - comecei a escrever o salvamento em um arquivo e acabou sendo muito trabalhoso - desisti e reescrevi a maior parte do código do zero novamente - é um trabalho meticuloso, vou ter que analisar todo o código fonte
Eu ficaria grato se você pudesse fornecer algum exemplo reproduzível (sem a pesquisa de histórico comercial).
Terei o maior prazer em retribuir sua utilidade. Infelizmente tenho dificuldades em forjar códigos de trabalho curtos a partir de códigos muito grandes e complexos. O que também é muito específico (por exemplo, abre apenas uma pose de cada vez).
Assim, para Slava eu tive que colocar um esqueleto de código em vez de um exemplo compilável.
Mas vou tentar fazer algo, caso contrário minha consciência me atormentará. Mas não rapidamente.
PS: Eu tenho uma produtividade muito baixa em código escrito. Eu só o aceito por persistência. E ao mesmo tempo - super ocupado em colocar a EA em funcionamento em uma conta real o mais rápido possível. Eu invejo sua produtividade.
OK, vamos esperar
Mas acabei sendo o oposto - já encontrei este problema - não coloquei a capacidade de salvar na estrutura do programa, e comecei a escrever salvando em um arquivo, tudo se tornou muito pesado.... Eu já encontrei este problema - eu não coloquei o salvamento em um arquivo na estrutura do programa e comecei a escrever o salvamento em um arquivo, e acabou sendo muito trabalhoso - então eu desisti e reescrevi a maior parte do código do zero novamente - imho, se você planeja salvar em um arquivo, você deve implementá-lo imediatamente, pelo menos com "stubs", caso contrário você terá que coletar tudo o que quiser salvar em cada classe - trabalho muito trabalhoso, na verdade você terá que analisar todo o código fonte
Os métodos de salvar/carregar são declarados inicialmente. E no objeto de base CObjeto da biblioteca padrão. A implementação de salvar em um arquivo em cada objeto da biblioteca pode ser descrita para um ou dois objetos. Mas escrever em cada artigo descrições de métodos de economia/carga - será um tanto chato ler quase a mesma "ação" de artigo para artigo, e simplesmente omitir - não é agradável para o leitor (e assim algumas pessoas dizem que é difícil para elas ler tais volumes de artigos, eu acho - você também). Portanto - esta tarefa para a descrição em dois ou três artigos mais próximos do final - de uma só vez, e não sobrecarregando muito o leitor.
Outra coisa seria se nada fosse descrito nos artigos - então é claro que seria necessário de imediato. Tudo depende das especificidades da história e dos objetivos. Se a finalidade - kodobaza, então tudo de uma vez, e se a finalidade - artigos de treinamento - então gradualmente - quando chegar o momento. Eu tenho a segunda opção.
A OnTradeTransaction foi mencionada novamente. Não há problema em garantir aOnTradeTransaction em caso de perda de conexão, etc., pois o terminal ainda sincronizará o ambiente comercial assim que a conexão for restaurada. Como aOnTrade é secundária, isso significa que você pode confiar neles. Se os próprios desenvolvedores não cometeram um erro, mas se eles removeram a cláusula, significa que tudo está bem.
Mas caber em cada artigo descrições de métodos de salvamento/carregamento - será bastante chato ler quase a mesma "ação" de artigo para artigo, e simplesmente omitir - não é agradável para o leitor (e assim alguns dizem que têm dificuldade de ler tais volumes de artigos, eu acho - você também). Portanto - esta tarefa para a descrição em dois ou três artigos mais próximos do final - de uma só vez caiu de uma só vez, e não sobrecarregando muito o leitor.
Eu não disse que o volume de artigos a ler é muito grande, mas escrevi que a quantidade de fontes é enorme e impossível de descobrir como usá-la sem algum tipo de ajuda/FAQ
Vou esperar pela implementação de salvar uma quantidade tão grande de dados, é interessante ver como vai ficar
A implementação da economia de tantos dados terá de esperar, será interessante ver como será
ok