Galerie der in MQL geschriebenen UIs - Seite 53
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
Rether, würden Sie in Betracht ziehen, den Katalog in zukünftigen Versionen auf Englisch umzustellen? Die Quellcode-Dateien, die die Katalognamen enthalten, werden durch Text ersetzt.
Ja, natürlich. Ich habe bereits darüber nachgedacht. Ich werde eine spezielle Release-Version mit englischen Katalognamen erstellen.
Ich bin nicht die Dateien nur die Kommentare hier zu überprüfen. Aber diese 'Verzögerung' scheint bei mir nicht mit der Geschwindigkeit zu tun zu haben, sondern mit der Verwendung von ChartRedraw, bevor die neue Ressource vollständig erstellt wird. Denn es blinkt mit einer leeren Leinwand und zeigen dann die neue Leinwand.
Ja, sicher. Ich habe darüber nachgedacht. Ich werde eine Sonderveröffentlichung machen, die den englischen Katalognamen enthält.
Ich würde vorschlagen, keine spezielle Version mit englischen Katalogen zu machen, sondern nur eine solche englische Version zu machen, indem man einfach den Namen des Katalogs in Englisch ändert, und der nächste Schritt wäre, den Dateinamen in Englisch zu ändern, und den Quellcode weiterhin in Russisch zu schreiben.
Ich stimme zu. Ich werde nach und nach auf englische Namen für Verzeichnisse umsteigen. So wird es rationeller sein.
Ich habe die Dateien nicht überprüft, nur die Kommentare hier. Aber diese "Verzögerung" scheint bei mir nicht mit der Geschwindigkeit zu tun zu haben, sondern mit der Verwendung von ChartRedraw, bevor die neue Ressource vollständig erstellt ist. Denn es blinkt eine leere Leinwand und zeigt dann die neue Leinwand.
Interessante Idee, ich werde versuchen, sie zu testen. Danke!
Und nun ein Update...
Dies ist ein Zwischen-Update. Ich werde die nächste Version in ein paar Tagen veröffentlichen. Es wird neue Funktionen für die Interaktion des Programms mit Steuerungen geben.
Ich muss dazu sagen, dass ich an zwei Builds arbeite - 2470 und die neue Version. Der größte Teil der Entwicklung findet auf dem alten Build statt. Die Kompilierung ist dort schneller - 4 Sekunden im Vergleich zu 26-32 Sekunden. Der neue Build arbeitet etwas anders, und das macht sich bemerkbar. Manchmal ist er schneller, manchmal langsamer. Vielleicht fühlt es sich auch nur so an. Es ist schwer, einen Unterschied zu finden, aber für mich scheint er vorhanden zu sein. Die Oberfläche der alten Version fliegt. Bei der neuen Version. fast fliegt. Vielleicht liegt es daran, dass ich mich daran gewöhnt habe.
Allerdings gibt es Nuancen. Zum Beispiel gibt es ein Problem beim Umschalten von Diagrammen, wenn falsche Werte für Höhe und Breite des Diagramms zurückgegeben werden. Dies führt dazu, dass die Taskleiste springt. Ich habe es geschafft, dieses Problem zu umgehen, aber dann reagiert die Taskleiste nicht auf andere Ereignisse der Diagrammgrößenänderung. Am Ende habe ich beschlossen, es so zu lassen, wie es war. Die Taskleiste springt beim Umschalten des Diagramms (solange es ein Problem mit der Rückgabe falscher Werte gibt), aber sie passt sich bei anderen Ereignissen normal an.
Aber das ist noch nicht alles. Es stellt sich heraus, dass die Ereignisse zur Größenänderung des Diagramms nicht sofort eintreten, sondern eine Pause von einer halben Sekunde eintritt. Diese Verzögerung überlagert sich mit der Zeit, in der die Taskleiste neu gezeichnet wird, und man erhält eine anständige Verzögerung. Hier bin ich machtlos.
Ich sage nur so viel: Natürlich habe ich die Grafik deutlich beschleunigt, aber es gibt noch einige andere nicht optimierte Lösungen im Code. Ich arbeite hart an ihnen. Meistens geht es um den Übergang des Fensterfokus und die Redraw-Warteschlange. Es passieren einige unnötige Aufrufe. Die Taskleiste verzögert sich. Ich habe das behoben, wozu ich Zeit hatte, wenn auch nicht alles. Aber der Rest ist eine Sache der nächsten Tage. Ansonsten gibt es nicht viel zu verbessern... vielleicht nur, um den Code zu kämmen und zu parfümieren, damit er duftet)).
Im Allgemeinen, wenn wir alle verbleibenden nicht optimierten Lösungen debuggen - wird es fliegen... natürlich im Rahmen der für ein MQL-Programm verfügbaren Geschwindigkeiten.
Nehmen Sie die Veröffentlichung.
Und so, ein Update...
...
Ich will es mal so sagen: Die Grafik hat sich natürlich deutlich beschleunigt, aber es gibt noch einige andere nicht optimierte Lösungen im Code. Ich arbeite hart an ihnen. Hauptsächlich geht es um den Fensterfokusübergang und die Redraw-Warteschlange. Es passieren einige unnötige Aufrufe. Die Taskleiste verzögert sich. Ich habe das behoben, wozu ich Zeit hatte, wenn auch nicht alles. Aber der Rest ist eine Sache der nächsten Tage. Ansonsten gibt es nicht viel zu verbessern... vielleicht einfach den Code kämmen und parfümieren, damit er duftet)).
Im Allgemeinen, wenn wir alle verbleibenden nicht optimierten Lösungen debuggen - wird es fliegen... nun, innerhalb der Geschwindigkeiten, die einem MQL-Programm zur Verfügung stehen, versteht sich.
Nehmen Sie die Veröffentlichung.
Lassen Sie es mich klar sagen: Wir sprechen hier über Geschwindigkeit. Wenn Sie die Fehler beim Neuzeichnen des Fensters beim Fokuswechsel beheben, wird die Schnittstellengeschwindigkeit an der oberen Grenze eines MMS-Programms liegen. Die Lags der Taskleiste können teilweise behoben werden. Ich habe eine gute Lösung gefunden - in der Mechanik der Taskleiste das Prinzip eines dynamischen Fensters anzuwenden - es verlangsamt sich nicht bei Größenänderung, wenn es vom Rahmen gezogen wird. Es wird sich schneller und unmerklicher anpassen. Und natürlich müssen wir unnötige Redraws abschaffen. Das ist obligatorisch. Aber wenn die CHARTEVENT_CHART_CHANGE-Ereignisse selbst mit einer Verzögerung zum Programm kommen, ist die sichtbare Verzögerung der Reaktionen der Taskleiste unvermeidlich, obwohl sie nichts damit zu tun hat.
Ansonsten gibt es viele Richtungen der Schnittstellenentwicklung und -verbesserung.
Noch ein paar Worte zur Geschwindigkeit der Schnittstelle.
Ich habe viel Zeit damit verbracht, Verzögerungen zu überprüfen und nach Rendering-Bremsen zu suchen. Der Block, der für das Kanvas-Layout verantwortlich ist, ist so aufgebaut, dass er vor der Initialisierung des Arrays, mit dem eine Ressource in der Funktion ResourceCreate() erstellt wird, die Grenzen der Schleife über die Fensterdetails definiert. Dies geschieht mit Hilfe von Bedingungsfiltern, die so konfiguriert sind, dass sie eingehende Ereignisse überprüfen. Jedes Ereignis, das den Block aufruft, erhält Zeichnungsgrenzen. So wird z. B. bei einem Ereignis, bei dem ein Element auf das Schweben des Cursors reagiert, der Filter mit den Schleifengrenzen nur für die Details eines bestimmten Elements aktiviert. Der Block wählt nur seine Details auf dem aufgenommenen Bild aus. Und während des Zyklus auf Details, zeichnet er selektiv nur sie unter dem Rest des Bildes. Er findet genau die Stellen, an denen das richtige Detail des richtigen Elements initialisiert und gezeichnet wird. Gleichzeitig wird der Rest des Bildes korrekt umgangen.
Aber die Beschleunigung ist nicht nur das. Der Block initialisiert die Punkte der Leinwand nicht, wenn ihre Farbe mit dem gewünschten Wert übereinstimmt. Außerdem "läuft" er nicht durch das Array, sondern "springt" und überbrückt Abstände. Dies reduziert die Zyklen um Hunderttausende von Iterationen.
Und nicht nur das. Da das Bild-Array global ist (auf globaler Ebene deklariert), speichert es immer die Änderung des letzten Bildes in seinem Speicher. Und wenn auf derselben Leinwand weiterhin Änderungen auftreten, wird das gespeicherte Bild verwendet, anstatt jedes Mal das Array zu löschen. Wenn sich der Ressourcenname beim nächsten Ereignis nicht ändert, muss ResourceReadImage() nicht aufgerufen und das Canvas-Array nicht erneut zum Füllen gesendet werden. Der Block arbeitet mit den restlichen Daten weiter , ohne ResourceReadImage() aufzurufen , und aktualisiert das Bild nach der Änderung mit ResourceCreate().
Dies spart eine Menge Zeit bei ResourceReadImage()-Aufrufen. Und auch beim Leeren und Füllen des Arrays. Das ist eine gute Verwendung des globalen Speichers, nicht wahr?
Wenn Fenster neu gezeichnet werden, wird der Block überhaupt nicht aufgerufen. Fensterkomponenten werden gelöscht und neu erstellt, und zuvor gespeicherte Ressourcen werden an sie angehängt. Es findet kein Rendering statt.
Trotz alledem kommt es immer noch zu Verzögerungen, die unvermeidlich sind. Lassen Sie mich erklären, was hier vor sich geht.
Beim ersten Öffnen eines Fensters, beim ersten Öffnen einer Registerkarte, beim Aufrufen einer Baumliste oder beim Minimieren/Entmodellieren großer Bereiche werden die Leinwände zwangsläufig vollständig neu gezeichnet. Bis zum Zeitpunkt der Erstellung von Bildressourcen, die später effizient verknüpft/geändert werden können, muss IMMER EINMAL ein komplettes Bild von Grund auf neu gezeichnet werden. Die erste Zeichnung ist IMMER die längste. Es gibt nichts zu speichern, es gibt kein gespeichertes Bild. Wenn Sie es zum ersten Mal öffnen, können Sie immer Verzögerungen feststellen. Das ist unvermeidlich.
Aber auch hier gibt es eine gute Lösung: Verschieben Sie die Verzögerungen beim Öffnen von Fenstern auf das Ladeereignis. Was ich meine: in der Phase des Ladens des Konstruktors im Hintergrund alle Bilder zeichnen und sie in den Ressourcen im Voraus speichern, so dass alles bereit wäre beim Öffnen. Dann sieht der Benutzer keine Verzögerungen, wenn er das Fenster zum ersten Mal öffnet. Das ist natürlich großartig, aber es gibt auch einen Nachteil. Die Verzögerung beim ersten Öffnen wird sich in eine Verzögerung beim Laden verwandeln, und die Zeit wird sich verlängern. Es ist schwer zu sagen, wie sehr. Ich denke, im Durchschnitt innerhalb einer Sekunde. Das hängt von der jeweiligen Schnittstelle ab.
Ich denke, diese Option ist vorzuziehen. Ich würde den Designer/die Benutzeroberfläche lieber etwas länger laden lassen, aber dafür gibt es keine Verzögerungen beim Öffnen der Seite mehr.
Ich bin gespannt auf Ihre Meinung dazu.
Hinzugefügt:
Es gab die Idee, die Ressourcen der Benutzeroberfläche nach dem ersten Laden in einer Datei zu speichern. Dann werden nachfolgende Ladevorgänge viel schneller sein, weil die notwendigen Ressourcen bereits dem Designer/Engine zur Verfügung stehen. Ich muss darüber nachdenken.