Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 34
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Die Anwendung ist getrennt, die grafische Benutzeroberfläche ist getrennt.
Die Verarbeitung der in der GUI abgeleiteten Daten erfolgt jedoch ohnehin synchron.
Die Anwendung sendet z. B. 10000 Elemente an GUI und GUI verarbeitet alle diese Elemente nacheinander.
Das ist das Problem. Es ist notwendig, die Verarbeitung der eingehenden Elemente und deren Ausgabe in der GUI zu parallelisieren. Basis, Text, Symbol.
Darüber hinaus gibt es drei Zyklen pro Zelle.
Das ist richtig. Aber unter den gegenwärtigen Umständen ist eine parallele Verarbeitung unpraktisch. Wir müssen mehr EAs oder Dienste verbinden. Es wird sich als eine schwerfällige und unzusammenhängende Umsetzung erweisen.
Es gibt einen Weg, der auf Objektdiagrammen basiert. Ich habe mich noch nicht damit befasst, aber es kann mir helfen, mehrere Themen zu erstellen. Es hat etwas mit Vorlagen zu tun...
Ich habe verstanden, dass die Anwendung und die grafische Benutzeroberfläche getrennt sind.
Die Verarbeitung der Ausgabedaten im GUI erfolgt jedoch ohnehin synchron.
So sendet die Anwendung beispielsweise 10000 Elemente an GUI und GUI verarbeitet alle diese Elemente nacheinander.
Das ist das Problem. Es ist notwendig, die Verarbeitung der eingehenden Elemente und deren Ausgabe in der GUI zu parallelisieren. Basis, Text, Symbol.
Dies gilt umso mehr, als eine Zelle drei Zyklen aufweist.
Dies wird wahrscheinlich nicht funktionieren. Auch die winda verarbeitet die Schnittstelle in einem einzigen Thread. Andernfalls werden die Fenster und Bedienelemente nicht vorrangig behandelt. Nur die grafische Benutzeroberfläche selbst und die Verarbeitung der verschiedenen Daten können in Threads aufgeteilt werden. De facto ist sogar die Änderung von Daten in Steuerelementen von einem anderen Thread aus nicht erlaubt. Ein Dialog muss immer kohärent sein, d.h. das Rendering und die Reaktion auf einen Dialog erfolgen ausschließlich in einem Thread, d.h. alles geschieht synchron.
Alle Vorgänge in MT sind strikt synchron, und dies kann nicht wirklich geändert werden, es sei denn, die Entwickler fügen der Anwendung Threads hinzu.
Es ist ziemlich überraschend, dass Entwickler versuchen, die MT-Funktionalität im Hinblick auf die Arbeit mit Datenbanken, mit Python, mit Sharpe... aber sie bieten an, das alles im selben Thread zu tun...
Es ist einfach erstaunlich.
Ich bin mit der Überraschung einverstanden.
Der einzige Ausweg besteht darin, eine Dll mit asynchronen Funktionen für Ihre Anwendungen zu sägen.
Aber solche Anwendungen können nicht einmal in der kodobase platziert werden, weil die dll nicht erlaubt ist.
Dies wird wahrscheinlich nicht funktionieren. Selbst die Windows-Schnittstelle wird in einem einzigen Thread bearbeitet. Andernfalls werden die Fenster und Bedienelemente nicht vorrangig behandelt. Nur die grafische Benutzeroberfläche selbst und die Verarbeitung der verschiedenen Daten können in Threads aufgeteilt werden. De facto ist sogar die Änderung von Daten in Steuerelementen von einem anderen Thread aus nicht erlaubt. Ein Dialog muss immer kohärent sein, d.h. das Rendering und die Reaktion auf einen Dialog erfolgt ausschließlich in einem Thread, d.h. alles geschieht synchron.
Es scheint mir, dass alles klappen wird, man muss nur die Priorität der asynchronen Datenverarbeitung im Voraus überdenken.
Das heißt, um ein Schema der asynchronen Verarbeitung, mit synchroner Verarbeitung zu bauen.
Ich stimme zu, mit Überraschung.
Der einzige Ausweg besteht darin, eine Dll mit asynchronen Funktionen in Ihre Anwendungen zu sägen.
Aber solche Anwendungen können nicht einmal in einer kodobase platziert werden, weil die dll nicht erlaubt ist.
Tatsächlich besteht noch keine wirkliche Notwendigkeit, die GUI-Ereignisverarbeitung zu parallelisieren. Wenn Tabellen mit 1000 Zellen selbst auf MT4 relativ schnell laufen, ist mehr als genug Geschwindigkeit für den Rest der Ereignisse vorhanden. In meiner Praxis gibt es keine Verlangsamung. Wenn Sie superschnelle Animationen benötigen, können Sie OpenCL anschließen. MT5 beherrscht die reguläre GUI perfekt. Überhaupt keine Probleme. Ich habe soeben gezeigt, dass man beim Nachzeichnen der Leinwand sehr aufmerksam sein muss.
Wenn der Expert Advisor selbst umfangreiche Berechnungen enthält, kann die Häufigkeit der Datenausgabe in der GUI reduziert werden. Das Neuzeichnen eines großen Fensters kann bis zu 100 ms dauern, liegt aber in der Regel deutlich darunter. Eine Verzögerung von 100 ms auf der grafischen Benutzeroberfläche macht sich also nur bei sehr umfangreichen EA-Berechnungen bemerkbar.
Ich stimme zu, mit Überraschung.
Der einzige Ausweg besteht darin, eine Dll mit asynchronen Funktionen für Ihre Anwendungen zu sägen.
Aber solche Anwendungen können nicht einmal in einer kodobase platziert werden, weil die dll verboten ist.
Viele Dinge können auf DLL-Ebene erledigt werden.
Das ist alles, wofür MT nicht ausgelegt ist und was man dort machen kann+muss+macht :-)
Man kann den Dll nicht kontrollieren, deshalb ist er nicht auf dem Markt. Dlls finden Sie übrigens in kodobase. Vielleicht haben sie es jetzt aus irgendeinem Grund verboten.
PS übrigens neugierige Frage - DLL kann mit dem Schlüssel des Entwicklers signiert werden. Es ist möglich, eine solche DLL auf dem Marktplatz und auch in kodobeise zuzulassen, aber sie wird an die Microsoft-Infrastruktur gebunden sein. Ist jemand hier bereit, eine solche Lizenz für Visual C zu kaufen?Ich stimme zu, mit Überraschung.
Der einzige Ausweg besteht darin, eine Dll mit asynchronen Funktionen für Ihre Anwendungen zu sägen.
Aber solche Anwendungen können nicht einmal in einer kodobase platziert werden, weil die dll verboten ist.
Ja, das ist das Hauptproblem! Der gleiche Markt verbietet die Verwendung von DLLs, so dass wir das Rad neu erfinden müssen. Ok, wenn jemand denkt, dass GUI nicht benötigt wird, aber komplexe lange Berechnungen in jedem Fall in einem Thread werden nicht funktionieren, alles wird hängen! Also muss es in einer Delle geschehen... was auf dem Marktplatz verboten ist...
Und so weiter. Aus diesem Grund muss ich alles mit mql-Methoden zeichnen und lösen.
In der Tat ist die Trennung von GUI und Logik in Threads natürlich bereits möglich. Hier wurde das Thema Parallelität bereits diskutiert https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
Als Ergebnis könnte das Formular selbst im Haupt-Thread belassen werden, wie es in winnda gemacht wird, während alle zusätzlichen Berechnungen in die "Hintergrund"-Ausführung verschoben werden könnten. So funktionieren Windows, Linux und Android.
Auf DLL-Ebene können Sie so viele Dinge tun.
Dafür ist MT nicht da und kann+muss+das tun :-)
Man kann den Dll nicht kontrollieren, deshalb ist er nicht auf dem Markt. Wir haben übrigens dlls in kodobase. Vielleicht haben sie es jetzt aus irgendeinem Grund verboten.
PS übrigens neugierige Frage - DLL kann mit dem Schlüssel des Entwicklers signiert werden. Es ist möglich, solche DLLs auch auf dem Marktplatz und in kodobeise zuzulassen, aber es wird an die Microsoft-Infrastruktur gebunden sein. Ist jemand hier bereit, eine solche Lizenz für Visual C zu kaufen?Ja, Sie können die DLL nicht kontrollieren, aber Sie könnten die gleichen Windbibliotheken zulassen...
Gehen Sie nicht einmal so weit: sogar als Teil einer Standardbibliothek gibt es Funktionen für den Zugriff auf winAPI! Aber was soll das bringen? Immerhin, es kann noch nicht in den Markt gestellt werden....
Okay, mit all diesem Gerede sind wir in eine weitere Flut geraten.
Auf DLL-Ebene können Sie viele Dinge tun.
Dafür ist MT nicht gedacht und kann+muss+dort gemacht werden :-)
Man kann die Ill nicht kontrollieren, deshalb ist sie nicht auf dem Markt. Und in kodobase finden Sie übrigens dlls. Vielleicht haben sie es aus irgendeinem Grund verboten.
PS übrigens neugierige Frage - DLL kann mit dem Schlüssel des Entwicklers signiert werden. Es ist möglich, solche DLLs auch auf dem Marktplatz und in kodobeise zuzulassen, aber es wird an die Microsoft-Infrastruktur gebunden sein. Ist jemand hier bereit, eine solche Lizenz für Visual C zu kaufen?Warum sollten Sie sich an die Microsoft-Infrastruktur binden?
Ich denke, dass absolut jeder Schlüssel zum Signieren einer DLL verwendet werden kann, solange er von MQ kontrolliert wird.
Daraus folgt, dass diese Schlüssel von MQ ausgegeben werden müssen und den Hash-Betrag der Anwendung kontrollieren.
Warum sollten sie sich an die Infrastruktur von Microsoft binden?
Ich denke, dass jeder Schlüssel zum Signieren einer DLL verwendet werden kann, solange er von MQ kontrolliert wird.
Daraus folgt, dass diese Schlüssel von MQ ausgegeben werden müssen und die Hash-Summe der Anwendung steuern.
sondern weil Microsoft der Chef in diesem Ameisenhaufen ist :-)
Was glauben Sie, warum Menschen ihre Anmeldedaten verlieren, wenn sie Produkte auf raubkopiertem Vin aktualisieren und aktivieren?