Galerie der in MQL geschriebenen UIs - Seite 55
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
Ich habe auch die Vollbild-Leinwand vollständig neu gezeichnet jedes Mal, wenn ich ändern, aber es dauert nicht länger als 50ms ...
Am teuersten ist es, Text zu zeichnen. Daher, um nicht jedes Mal TextOut zu verwenden, speichere ich sie in Arrays. Es stellt sich heraus, viel schneller.
Ja, TextOut wird verwendet. Ich werde darüber nachdenken, was man damit machen kann.
Nun, einfache Arithmetik funktioniert hier: die Summe der Flächen von 10 - 17 Fenstern ist viel größer als der gesamte Bildschirm. Stimmt. Plus sekundäre zusätzliche Zeichnungen, die notwendig sind, um Schatten, Icons, Rahmen zu erstellen....
Und über TextOut werde ich prüfen und schreiben. Interessante Idee.
Ich verstehe Ihre einfache Arithmetik nicht :). In meiner Arithmetik gibt es keine Notwendigkeit, die Pixel zu zeichnen, die für den Benutzer nicht sichtbar sind, und die maximale Größe der Leinwand zum Zeichnen ist durch die Anzeigegröße in Pixeln begrenzt.
Ich zeichne in Ebenen, egal wie viele Fenster, alle in einer Bitmap. Es kann bis zu hundert Fenster geben. Einfache Primitive werden in einer winzigen Zeitspanne gezeichnet. Das längste, wie ich oben schrieb, sind Texte. Aber die werden mit Hilfe von TextOut bei der ersten Verwendung, und weiter bereits aus fertigen Arrays.
Ein Plan für die künftige Arbeit muss noch genehmigt werden.
Ich werde jede Woche ein Update veröffentlichen. Samstag oder Sonntag.
1. In der nächsten Version werde ich eine Vollversion der Engine veröffentlichen. Ich werde Bugs beheben und das Rendering beschleunigen.
2. Die zweite Version wird den Tabellen gewidmet sein. Ich werde die grundlegenden Funktionen wiederherstellen.
3. die dritte Version - ich werde dynamische Tabellen machen. Ich hoffe, dass ich sie in einer Woche implementieren kann. Ich werde es versuchen.
4. Vierte Version - dynamisches Fenster. Ich werde versuchen, die fertige Version zu veröffentlichen.
In diesem Stadium können die Grundversionen des Builders, der Engine und der Auszeichnungssprache als vollständig angesehen werden.
Ich werde auf jeden Fall einen Zweig für in KIB-Code geschriebene Vorlagen eröffnen, wo ich fertige Fenster und Elementgruppen veröffentlichen werde. Mit Illustrationen, um es denjenigen zu erleichtern, die die Schnittstelle bauen wollen.
Und ich werde versuchen, Tutorial-Artikel zu schreiben, damit die Leute die ganze Bandbreite der Möglichkeiten nutzen können.
In diesem Thread werde ich weiterhin Code, Bilder und erklärendes Material posten, so gut ich kann. Ich werde sehr damit beschäftigt sein, die oben erwähnte Arbeit zu erledigen.
Ich verstehe Ihre einfache Arithmetik nicht :). In meiner Arithmetik gibt es keine Notwendigkeit, die Pixel zu rendern, die für den Benutzer nicht sichtbar sind, und die maximale Größe der Leinwand für das Rendering ist durch die Anzeigegröße in Pixel begrenzt.
Ich zeichne in Ebenen, egal wie viele Fenster, alle in einer Bitmap. Es kann bis zu hundert Fenster geben. Einfache Primitive werden in einer winzigen Zeitspanne gezeichnet. Das längste, wie ich oben schrieb, sind Texte. Aber die werden mit Hilfe von TextOut bei der ersten Verwendung, und weiter schon aus fertigen Arrays.
Das Arbeiten mit einem großen Canvas hat eine Menge Einschränkungen. Ich habe bereits über diese Option nachgedacht und sogar mit Nikolay diskutiert.
Lassen Sie mich erklären: Sie tun es, weil Sie die Standard-Canvas-Klasse verwenden. Es gibt fertige Lösungen, in deren Rahmen Sie arbeiten. Aber ich verwende die Ccanvas-Klasse nicht. Alle Rendering-Codes sind Eigenentwicklungen. Deshalb halte ich mich auch nicht an das Konzept - ein Canvas für ALLES. Meiner Meinung nach ist das eine technisch unbequeme und ineffiziente Lösung in einer grafischen Umgebung. Es ist einfacher, eine Reihe von Bitmap-Objekten zu verwenden und ihnen vorgefertigte Ressourcen zuzuordnen, als eine Bitmap zu haben und die Interaktion der Bilder darauf programmatisch aufzubauen. Das ist sogar schwer vorstellbar. Aber das ist nicht der springende Punkt.
Stellen Sie sich vor, wie viel schwieriger es ist, das Konzept einer Mehrfenster-GUI zu realisieren, wenn Sie nur EINE Leinwand haben. Ich würde eine solche Aufgabe nicht übernehmen.
Aber auch das ist nicht entscheidend. Der Hauptgrund für die Ablehnung der Idee eines Canvas für alle Bilder: Wenn es nur einen Canvas gibt, erfordert das Verschieben der Interface-Fenster ein Neuzeichnen innerhalb der MQL-Umgebung. Im Gegensatz dazu, wenn jedes Fenster sein eigenes Bitmap-Objekt belegt und durch die Funktion ObjectSetInteger() verschoben wird, - fällt das Neuzeichnen der verschobenen Objekte auf Standardfunktionen, die außerhalb der MQL-Umgebung arbeiten. Daher ist es viel schneller.
Sie haben einfach eine andere Entwicklungsrichtung, in der andere Lösungen effektiver arbeiten.
Vielen Dank für den Hinweis auf TextOut. Ich werde diesen Punkt untersuchen.
Die Vorlagenzweige sindin KIB-Code geschrieben, der
Ja, für das Debugging werde ich die Trennung des Benutzerprogramms von der Engine implementieren, wenn Sie das gemeint haben. Wahrscheinlich habe ich das falsch verstanden.
Die Arbeit mit einer großen Leinwand bringt viele Einschränkungen mit sich. Ich habe bereits über eine solche Option nachgedacht und sie sogar mit Nikolay besprochen.
Lassen Sie mich das erklären: Sie tun es, weil Sie die Standardklasse Ccanvas verwenden. Es gibt fertige Lösungen, in deren Rahmen Sie arbeiten. Aber ich verwende die Ccanvas-Klasse nicht. Alle Rendering-Codes sind durch Eigenentwicklung entstanden. Ich halte mich also nicht an das Konzept - eine Leinwand für ALLES. Meiner Meinung nach ist das eine technisch unbequeme und ineffiziente Lösung in einer grafischen Umgebung. Es ist einfacher, eine Reihe von Bitmap-Objekten zu verwenden und ihnen vorgefertigte Ressourcen zuzuordnen, als eine Bitmap zu haben und die Interaktion der Bilder darauf programmatisch aufzubauen. Das ist sogar schwer vorstellbar. Aber das ist nicht die Hauptsache.
Stellen Sie sich vor, wie viel schwieriger es ist, das Konzept einer Mehrfenster-GUI zu realisieren, wenn Sie nur EINE Leinwand haben. Ich würde eine solche Aufgabe nicht auf mich nehmen.
Aber auch das ist nicht entscheidend. Der Hauptgrund für die Ablehnung der Idee eines Canvas für alle Bilder: Wenn es nur einen Canvas gibt, erfordert das Verschieben der Interface-Fenster ein Neuzeichnen innerhalb der MQL-Umgebung. Im Gegensatz dazu, wenn jedes Fenster sein eigenes Bitmap-Objekt belegt und durch ObjectSetInteger() verschoben wird, - fällt das Neuzeichnen beim Verschieben auf Standardfunktionen, die außerhalb der MQL-Umgebung arbeiten. Daher ist es viel schneller.
Sie haben nur eine etwas andere Entwicklungsrichtung, in der andere Lösungen effizienter arbeiten.
Vielen Dank für den Hinweis auf TextOut. Ich werde diesem Punkt nachgehen.
Ich verwende einfach NICHT die Standard-Kanvas :).
Und ich fand es einfach einfacher, eine Multi-Fenster-Schnittstelle auf einer Bitmap zu implementieren. Aber jedem das Seine!
Und in der Praxis scheint es schneller zu sein, die gesamte Leinwand neu zu zeichnen, als ObjectSetInteger zu verwenden, etc....
Ich verwende einfach NICHT die Standard-Leinwand :).
Und ich fand es einfach einfacher, eine Multi-Fenster-Schnittstelle auf einer Bitmap zu implementieren. Aber jedem das Seine!
Leider nicht in allen Fällen. Für meine Aufgaben ist es technisch einfacher, mit einer begrenzten Anzahl von Bitmaps zu arbeiten. Und 100% schneller. Viel schneller.
Aber für andere Entwicklungen funktionieren andere Lösungen besser, und so ja - jedem das Seine. :)