L'abonnement à OnBookEvent est parfois interrompu - existe-t-il une telle chose ? - page 2
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
"Il suffit qu'un expert se désinscrive pour ne plus recevoir l'événement, et tous les autres experts cesseront de le recevoir aussi" ?
C'est juste une supposition pour savoir si cela vaut la peine ou non - dans l'analogie de continuer que "tout ce qu'il faut pour qu'un EA se désabonne de la réception d'un événement, et tous les autres EA cesseront de le recevoir aussi" ? Je ne pense pas qu'une telle chose puisse exister, ce serait (ou c'est) un bug.
D'abord, c'est facile à vérifier. Je le ferais bien moi-même, mais je n'ai qu'un compte FORTS et il est fermé le week-end.
Mais si c'est le cas, la situation s'avère drôle. Lorsque vous avez activé le conseiller expert et l'indicateur, les abonnements ont été déclenchés. Lorsque vous désactivez le conseiller expert ou l'indicateur, vous avez déjà écrit que les abonnements se sont effondrés. Cela suggère que la diffusion fonctionne dans le sens inverse. Imaginons maintenant que quelque chose ait changé (par exemple, l'historique a changé et l'indicateur a été recalculé). Mais nous savons que OnInit et OnDeinit peuvent être appelés de façon aléatoire. Parfois c'est correct, et parfois c'est l'inverse. Que se passe-t-il si le graphique appelle d'abord la nouvelle version de l'indicateur, puis désinstalle l'ancienne ? L'abonnement va tomber. C'est ce que ça ferait de "tomber tranquillement". Je vous recommande de mettre des imprimantes dans OnInit et OnDeinit pour vérifier la file d'attente et le message au cas où les cotations boursières cesseraient d'arriver. Peut-être le problème se résorbera-t-il.
Tout d'abord, il est facile à vérifier. Je le ferais bien moi-même, mais je n'ai qu'un compte sur FORTS et il est fermé le week-end.
Vous n'avez pas besoin deCHARTEVENT_OBJECT_CREATE pour vérifier le score.
C'est une évidence.
Je ne comprends pas. Tu peux toujours mettre un compteur de liens.
Je ne comprends pas. Tu peux toujours mettre un compteur de liens.
Il n'y a pas de compteur. Et s'il y en avait un, il serait explicitement indiqué dans la documentation qu'il existe et qu'il n'est admissible que dans l'appel de la paire Add\Release - sinon le compteur sera cassé et le sens de son existence sera perdu.
Et si vous dites que vous avez besoin d'un compteur de référence... alors vous pourriez aller plus loin et abolir complètement la radiodiffusion.
Il n'y a pas de compteur. Et si c'était le cas, il serait clairement indiqué dans la documentation qu'il existe et que seul l'appel apparié Add/Release est autorisé - sinon le compteur sera perdu et le sens de son existence sera perdu.
et pour l'instant, la fonction de libération n'a aucun sens car la logique selon laquelle n'importe qui peut se désinscrire de votre événement est absurde.
Il existe une suggestion simple qui consiste à ne pas utiliser la fonctionMarketBookRelease.
En théorie, cela permettrait de gaspiller une partie des ressources du terminal et du serveur.
Mais en pratique... Y aura-t-il de réelles conséquences à cela ?
Il n'y a plus de raison d'utiliser la fonction de diffusion, car la logique selon laquelle n'importe qui peut se désinscrire de votre événement est absurde.
Il est inutile d'expliquer pour les hérissons, je vais donc écrire pour les autres ;-).
La notion de diffusion d'événements est une chose, mais les principes d'appel par paire des fonctions d'abonnement et de désabonnement à un événement en sont une autre. Il s'agit de techniques sémantiquement indépendantes qui ne doivent pas, et idéalement ne devraient pas, s'influencer mutuellement. Laisser l'événement être diffusé (ceci a probablement été fait pour des raisons d'efficacité, mais c'est très controversé et peut causer le problème actuel s'il est mal mis en œuvre). Cela signifie qu'il suffit qu'un seul s'inscrive pour que tous reçoivent l'événement. Mais à l'inverse - il faut se désabonner et tout le monde se fait avoir - c'est déjà une sorte de "narrowcasting".
Le compteur d'abonnés n'est pas mentionné dans la documentation, alors qu'il est très important (et la phrase sur la diffusion n'est pas une explication pour la raison ci-dessus). La diffusion devrait idéalement durer jusqu'à ce que le nombre d'abonnés tombe à 0. Sinon, il est évident que les programmes MQL (y compris ceux de différents développeurs) devraient communiquer entre eux d'une manière ou d'une autre, afin de ne pas nuire à leur travail, mais c'est un non-sens. Je ne connais pas un seul exemple de logiciel (au sens large, sans se limiter à MT, Windows, etc.) où l'abonnement a été mis en œuvre de cette manière.
Il y a ce passage sur MarketBookRelease :
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
C'est, encore une fois, ambigu. Cela pourrait être interprété comme un contrôle du nombre d'abonnements. Mais le logiciel ne permet pas les interprétations privées.
En fin de compte, IMHO, la mise en œuvre est un râteau (la vérification et la sursouscription est nécessaire au niveau MQL), la documentation est obscure. L'affirmation selon laquelle un code malveillant ou carrément mauvais peut tuer les abonnements des autres, même avec un compteur, n'est pas vraiment pertinente. Tous ces scripts pourraient faire du mal à un tas d'autres endroits dans le terminal (par exemple, supprimer les objets d'autres personnes, tuer les arrêts sur les positions d'autres personnes, etc. ce qui est déjà arrivé un million de fois). Il est inutile de parler de telles manifestations de piggyback pur et simple - elles ne peuvent être empêchées par rien d'autre que la discipline de l'utilisateur, la relecture du code des autres utilisateurs (s'il y en a) ou la vérification d'une démo. Le problème maintenant est que le code correctement écrit ne peut pas fonctionner correctement maintenant.
Si nous faisions ce mécanisme correctement, bien sûr - le schéma éditeur/abonné n'a pas été aboli. Cela n'affecterait certainement pas l'efficacité.