Die Anmeldung bei OnBookEvent fällt manchmal aus - gibt es so etwas? - Seite 2

 
Stanislav Korotky:

"Es genügt, wenn sich ein Experte vom Empfang der Veranstaltung abmeldet, und alle anderen Experten erhalten sie ebenfalls nicht mehr"?

Es ist ein Kinderspiel
 
Stanislav Korotky:

Es ist nur eine Vermutung, ob es sich lohnt oder nicht - in der Analogie, dass "es genügt, wenn sich ein EA vom Empfang eines Ereignisses abmeldet, und alle anderen EAs werden es auch nicht mehr erhalten"? Ich glaube nicht, dass es so etwas geben kann, es wäre (oder ist) ein Fehler.

Zum einen ist es leicht zu überprüfen. Ich würde es selbst tun, aber ich habe nur ein FORTS-Konto und das ist am Wochenende geschlossen.

Aber wenn es so ist, dann ist die Situation lustig. Wenn Sie Expert Advisor und Indikator aktiviert haben, werden die Abonnements ausgelöst. Wenn Sie den Expert Advisor oder den Indikator deaktivieren, haben Sie bereits geschrieben, dass die Abonnements abgestürzt sind. Dies deutet darauf hin, dass die Ausstrahlung in die entgegengesetzte Richtung wirkt. Stellen Sie sich nun vor, dass sich etwas geändert hat (z. B. hat sich der Verlauf geändert und der Indikator wurde neu berechnet). Aber wir wissen, dass OnInit und OnDeinit zufällig aufgerufen werden können. Manchmal ist es richtig, und manchmal ist es umgekehrt. Was passiert, wenn das Diagramm zuerst die neue Version des Indikators aufruft und dann die alte Version deinstalliert? Das Abonnement fällt weg. So wäre es, wenn man "still und leise abfallen würde". Ich würde empfehlen, in OnInit und OnDeinit Drucker einzubauen, um die Warteschlange und die Nachricht zu überprüfen, falls die Aktienkurse nicht mehr eingehen. Vielleicht wird sich das Problem lösen.

 
Sergey Savinkin:

Zunächst einmal ist es einfach zu überprüfen. Ich würde es selbst tun, aber ich habe nur ein Konto bei FORTS und das ist am Wochenende geschlossen.

Sie brauchenCHARTEVENT_OBJECT_CREATE nicht, um den Spielstand zu überprüfen.

 
https://yandex.ru/images/search?source=wiz&text=два%20выключателя%20на%20одну%20лампочку&img_url=https%3A%2F%2Frepair-need.ru%2Fuploads%2Fdico-kebfbf.jpg&pos=3&rpt=simage&lr=213
Яндекс.Картинки
  • yandex.ru
Результаты поиска по запросу "два выключателя на одну лампочку" в Яндекс.Картинках
 
A100:
Das ist ein Kinderspiel.

Ich verstehe das nicht. Sie können jederzeit einen Link-Zähler setzen

 
TheXpert:

Ich verstehe das nicht. Sie können jederzeit einen Link-Zähler setzen

Es gibt keinen Zähler. Und wenn es sie gäbe, würde in der Dokumentation ausdrücklich auf ihre Existenz und die Zulässigkeit von Add\Release-Paaraufrufen hingewiesen - andernfalls würde der Zähler kaputtgehen und die Bedeutung seiner Existenz ginge verloren

Und wenn Sie sagen, dass Sie einen Referenzzähler brauchen... dann könnte man noch weiter gehen und den Rundfunk ganz abschaffen

 
A100:

Es gibt keinen Zähler. Und wenn es einen gäbe, würde in der Dokumentation explizit darauf hingewiesen, dass er existiert und nur gepaarte Aufrufe von Hinzufügen/Freigeben erlaubt sind - andernfalls geht der Zähler verloren und die Bedeutung seiner Existenz geht verloren

und im Moment ist die Freigabefunktion bedeutungslos, weil die Logik, dass sich jeder von Ihrer Veranstaltung abmelden kann, unsinnig ist.

 

Es gibt einen einfachen Vorschlag, die FunktionMarketBookRelease einfach nicht zu verwenden.

Theoretisch würde dies einen Teil der Terminal- und Serverressourcen verschwenden.

Aber in der Praxis... Wird dies irgendwelche Konsequenzen haben?

 
TheXpert:

Nun hat die Freigabefunktion keinen Sinn mehr, denn die Logik, dass sich jeder von Ihrer Veranstaltung abmelden kann, ist unsinnig

Selbst wenn es einen Zähler gibt, kann sich jeder abmelden, indem er dieFreigabe so oft wie nötig aufruft- höchstwahrscheinlich wäre der Zähler nicht in der Lage, zusätzliche Anrufe zu erkennen, und das aktuelle Problem würde sich in ein Problem mit einem schlecht funktionierenden Zähler verwandeln. Und wenn Sie einen intelligenten Zähler verwenden könnten, könnten Sie auf die Übertragung als solche verzichten.
 

Es ist müßig, das für Igel zu erklären, also schreibe ich für andere ;-).

Der Begriff "Event Broadcasting" ist eine Sache, aber das Prinzip des paarweisen Aufrufs der Funktionen "subscribe" und "unsubscribe" für ein Ereignis ist eine andere. Es handelt sich um semantisch unabhängige Techniken, die sich nicht gegenseitig beeinflussen müssen und idealerweise auch nicht sollten. Lassen Sie das Ereignis übertragen (dies wurde wahrscheinlich aus Gründen der Effizienz getan, ist aber sehr umstritten und kann bei falscher Umsetzung das aktuelle Problem verursachen). Das bedeutet, dass es ausreicht, wenn sich einer anmeldet, damit alle das Ereignis erhalten. Aber im umgekehrten Fall - man muss sich abmelden und alle werden verarscht - ist das schon eine Art von Narrowcasting.

Der Zähler der Abonnenten wird in der Dokumentation nicht erwähnt, obwohl er sehr wichtig ist (und der Satz über die Ausstrahlung ist keine Erklärung für den oben genannten Grund). Broadcasting sollte idealerweise so lange dauern, bis die Anzahl der Abonnenten auf 0 sinkt. Andernfalls wäre es offensichtlich, dass MQL-Programme (auch die von verschiedenen Entwicklern) irgendwie miteinander kommunizieren müssten, um ihre Arbeit nicht zu beeinträchtigen, aber das ist Unsinn. Ich kenne kein einziges Beispiel von Software (im weitesten Sinne, nicht beschränkt auf MT, Windows usw.), bei der das Abonnement auf diese Weise umgesetzt wurde.

Es gibt diese Passage über MarketBookRelease:

Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().

Auch dies ist zweideutig. Dies könnte als Kontrolle über die Anzahl der Abonnements interpretiert werden. Die Software lässt jedoch keine privaten Interpretationen zu.

Unterm Strich, IMHO, die Umsetzung ist eine Rake (Überprüfung und Überzeichnung ist auf MQL-Ebene erforderlich), die Dokumentation ist undurchsichtig. Die Behauptung, dass böswilliger oder schlichtweg schlechter Code die Abonnements anderer sogar mit einem Zähler löschen kann, ist nicht wirklich relevant. Alle diese Skripte könnten an einer Reihe anderer Stellen im Terminal Schaden anrichten (z.B. Objekte anderer Leute löschen, Haltestellen anderer Leute zerstören, usw., was schon millionenfach passiert ist). Es hat keinen Sinn, über solche offenen Huckepack-Manifestationen zu sprechen - sie können durch nichts verhindert werden, außer durch die Disziplin der Benutzer, das Korrekturlesen des Codes anderer Benutzer (wenn es einen gibt) oder die Überprüfung einer Demo. Das Problem ist nun, dass ordnungsgemäß geschriebener Code nicht mehr ordnungsgemäß ausgeführt werden kann.

Wenn wir diesen Mechanismus richtig anwenden würden, wäre das Herausgeber/Abonnenten-Muster natürlich nicht abgeschafft. Die Effizienz würde dadurch sicherlich nicht beeinträchtigt.