A assinatura do OnBookEvent às vezes cai - existe algo assim? - página 2
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
"basta um especialista cancelar a inscrição para não receber o evento, e todos os outros especialistas deixarão de recebê-lo também"?
É apenas um palpite se vale ou não a pena - na analogia de continuar que "tudo o que é preciso é que uma EA se anule de receber um evento, e todas as outras EA deixarão de recebê-lo também"? Não creio que possa haver tal coisa, seria (ou é) um bicho.
Por um lado, é fácil de verificar. Eu mesmo o faria, mas só tenho uma conta FORTS e ela está fechada no fim de semana.
Mas se assim for, a situação se revela engraçada. Quando você habilitou o Expert Advisor e o indicador, as assinaturas foram acionadas. Quando você desabilita o Expert Advisor ou o indicador, você já escreveu que as assinaturas falharam. Isto sugere que a radiodifusão funciona na direção oposta. Agora imagine que algo mudou (por exemplo, a história mudou e o indicador foi recalculado). Mas sabemos que o OnInit e o OnDeinit podem ser chamados aleatoriamente. Algumas vezes é correto, outras vezes é o contrário. O que acontecerá se o gráfico chamar primeiro a nova versão do indicador, e depois desinstalar a antiga? A assinatura será cancelada. Isso é o que seria "cair calmamente". Eu recomendaria que você colocasse impressoras no OnInit e OnDeinit para verificar a fila e a mensagem no caso de as cotações de estoque pararem de chegar. Talvez o problema se esclareça.
Antes de mais nada, é fácil de verificar. Eu mesmo o faria, mas só tenho uma conta na FORTS e ela está fechada no fim de semana.
Você não precisaCHARTEVENT_OBJECT_CREATE para verificar a pontuação de forma alguma.
É um "nobrainer".
Não entendo. Você sempre pode colocar um contador de links
Não entendo. Você sempre pode colocar um contador de links
Não há contador. E se existisse, seria declarado explicitamente na documentação sobre sua existência e admissibilidade de chamada de par Add\Release apenas - caso contrário, o contador será quebrado e o significado de sua existência será perdido
E se você diz que precisa de um contador de referência... então você poderia ir mais longe e abolir totalmente a radiodifusão
Não há contador. E se houvesse, seria claramente declarado na documentação que existe e só é permitido acrescentar/liberar chamada emparelhada - caso contrário o contador será perdido e o significado de sua existência será perdido
e neste momento a função de liberação não tem sentido porque a lógica de que qualquer um pode cancelar a inscrição de seu evento é um disparate.
Há uma sugestão simples de simplesmente não utilizar a funçãoMarketBookRelease.
Em teoria, isto desperdiçaria alguns dos recursos do terminal e do servidor.
Mas na prática... Haverá alguma conseqüência real disso?
Bem, agora não há sentido na função de liberação. porque a lógica de que qualquer um pode cancelar a inscrição de seu evento é uma lógica sem sentido.
É inútil explicar para os porcos-espinhos, então vou escrever para os outros ;-).
A noção de transmissão de eventos é uma coisa, mas os princípios de chamar em pares as funções de assinatura e cancelamento de assinatura de um evento é outra. Estas são técnicas semanticamente independentes que não precisam, e idealmente não devem, afetar umas às outras. Deixe o evento ser transmitido (isto provavelmente foi feito por razões de eficiência, mas é muito controverso e pode causar o problema atual se implementado incorretamente). Isto significa que basta uma assinatura, para que todos recebam o evento. Mas ao contrário - é preciso cancelar a inscrição e todos se ferram - já é uma espécie de "narrowcasting".
Sobre o balcão de assinantes na documentação não é mencionado, embora seja muito importante (e a frase sobre radiodifusão não é uma explicação para o motivo acima). A radiodifusão deveria durar idealmente até que o número de assinantes diminua para 0. Caso contrário, é óbvio que os programas MQL (incluindo os de diferentes desenvolvedores) teriam que se comunicar de alguma forma, de modo a não prejudicar seu trabalho, mas isso é um absurdo. Não conheço um único exemplo de software (no sentido amplo, não limitado a MT, Windows, etc.) onde a assinatura foi implementada desta forma.
Há esta passagem sobre o MarketBookRelease:
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
É, mais uma vez, ambíguo. Poderia ser interpretado como tendo controle sobre o número de assinaturas. Mas o software não permite interpretações privadas.
Resumindo, IMHO, a implementação é um rake (verificação e sobre-assinatura é necessária em nível de MQL), a documentação é obscura. A afirmação de que código malicioso ou completamente ruim pode matar as assinaturas dos outros, mesmo com um contador, não é realmente relevante. Todos esses scripts poderiam causar danos em um monte de outros lugares no terminal (por exemplo, apagar objetos de outras pessoas, matar paradas em posições de outras pessoas, etc., o que já aconteceu um milhão de vezes antes). Não faz sentido falar sobre tais manifestações piggyback - elas não podem ser impedidas por nada, exceto pela disciplina do usuário, a revisão do código de outros usuários (se houver algum) ou a verificação de uma demonstração. O problema agora é que o código devidamente escrito não pode funcionar corretamente agora.
Se fizéssemos este mecanismo corretamente, é claro - o padrão editor/assinante não foi abolido. Isso certamente não afetaria a eficiência.