Galerie der in MQL geschriebenen UIs - Seite 71

[Edgar Akhmadeev]

Реter Konow #:
Es ist eine seltsame Taktik, zu lauern und zu warten. :) Wenn die Leute aktiv teilnehmen würden, würde ich meine Prioritäten nicht ändern.

Ich kann nur für mich selbst sprechen. Ich weiß nicht, wie ich helfen kann. Wie man sich aktiv beteiligen kann. Alles, was ich tun konnte, habe ich getan. Ich habe den Code auf der Grundlage der Informationen, die ich habe, geschrieben, ich habe eine schöne Schnittstelle geschaffen. Dann stecke ich fest, ohne zu wissen, was ich persönlich brauche. Und ich kann keine Lektionen darüber lernen, wie man etwas benutzt, das ich noch nicht in die Praxis umsetzen kann. Ich bin ein Praktiker. Deshalb werde ich auf jeden Fall Unterricht brauchen, wenn die Zeit dafür gekommen ist.

Verschiedene Kontrollknöpfe und Knöpfe zur Kontrolle verschiedener Dinge - ich persönlich werde sie später brauchen. Wenn ich dazu komme. Im Moment warte ich noch auf eine Schnittstelle für eine bequeme und schöne Anzeige. Und wir haben es nicht eilig, deshalb schubsen wir Sie auch nicht mit den Ellbogen. Wir haben Verständnis dafür, dass Sie nicht im Dienst sind. Ich fragte eine Frage nicht, weil ich in Eile bin, nur - sie irgendwo verschwunden.

[Реter Konow]

Edgar Akhmadeev #:

Ich kann nur für mich selbst sprechen. Ich weiß nicht, wie ich helfen kann. Wie ich mich aktiv beteiligen kann. Ich habe alles getan, was ich konnte. Ich habe den Code nach den verfügbaren Informationen geschrieben und eine schöne Schnittstelle erhalten. Dann stecke ich fest, ohne zu wissen, was ich persönlich brauche. Und ich kann nicht lernen, wie man etwas benutzt, das ich noch nicht in die Praxis umsetzen kann. Ich bin ein Praktiker. Deshalb werde ich auf jeden Fall Unterricht brauchen, wenn die Zeit dafür gekommen ist.

Verschiedene Kontrollknöpfe und Knöpfe zur Kontrolle verschiedener Dinge - ich persönlich werde sie später brauchen. Wenn ich dazu komme. Im Moment warte ich noch auf eine Schnittstelle für eine bequeme und schöne Anzeige. Und wir haben es nicht eilig, deshalb schubsen wir Sie auch nicht mit den Ellenbogen. Wir haben Verständnis dafür, dass Sie nicht im Dienst sind. Ich fragte eine Frage nicht, weil ich in Eile bin, nur - irgendwo verschwunden.

Wie ich festgestellt habe, wissen Sie noch nicht, welche Schnittstelle Ihre Anwendung benötigt. :) Da kann ich dir nicht helfen. Aber wenn Sie es herausgefunden haben, machen Sie eine Skizze. Es ist wahrscheinlich, dass die vorhandenen Fähigkeiten meines Designers und der Engine mehr als ausreichend sind. Wie ich schon sagte, fehlen nur drei wesentliche Dinge:

1. Dynamische Tabellen sind Tabellen mit einer unbegrenzten Anzahl von Zeilen.

2. Generierte Tabellen - das sind Tabellen, die von der Funktion "on the fly" gesammelt werden. Sie werden für die schnelle Ausgabe, Sortierung und den Vergleich einzelner Parameter aus großen Datensätzen benötigt.

3. wissenschaftliche Graphen wie in R. Sie sind bereits in der Standardbibliothek CGraphic und in der Bibliothek von Anatoly Kozharsky implementiert. Ich werde sie auf meine eigene Weise implementieren.

Alles andere steht in meinem Konstruktor. Überlegen Sie, was Ihre Anwendung braucht. Machen Sie eine Skizze. Poste sie hier. Ich werde dir helfen, Kib-Code zu schreiben.

[Реter Konow]

Edgar Akhmadeev #:

... Ich schrieb den Code nach den verfügbaren Informationen und bekam eine schöne Schnittstelle. Dann lief ich in unrealisiert, was ich persönlich brauchen. ....

Übrigens, was damals nicht funktionierte, funktioniert heute schon, denn es gibt eine Softwaresteuerung der Schnittstelle. Ich erinnere mich, dass wir damals keine Parameter an Ihre Tabellen ausgeben konnten. Jetzt ist das ganz einfach möglich. Ihre Tabelle kann funktionieren und Werte ausgeben. Es ist bereits in der Engine implementiert. Das ist nur für das Protokoll.

[Edgar Akhmadeev]

Ich weiß nicht nur, was benötigt wird, sondern ich habe auch das Mockup erstellt. Hier ist Ihr korrigierter Code und Layout https://www.mql5.com/ru/forum/467909/page37#comment_53863397.

Ich brauche genau (in Ihren Worten) dynamische und generierte Tabellen. D.h. programmatisch hinzufügen eine unbestimmte Anzahl von Zeilen (gut, begrenzt durch den gesunden Menschenverstand), füllen sie, bequem scrollen die Tabelle selbst, nicht den Rahmen mit ihm. So dass die Überschriften an ihrem Platz bleiben.

Das ist es, was Sie bis jetzt in Arbeit haben. Deshalb sitze ich ruhig auf meinem Hintern und warte. Ich selbst habe es nicht eilig, und ich habe es auch nicht eilig für dich. Ich werde ewig leben. Bis jetzt klappt es.

[Реter Konow]

Edgar Akhmadeev #:

Ich weiß nicht nur, was benötigt wird, sondern ich habe auch das Mockup erstellt. Hier ist Ihr korrigierter Code und Layout https://www.mql5.com/ru/forum/467909/page37#comment_53863397

Ich brauche genau (in Ihren Worten) dynamische und generierte Tabellen. D.h. programmatisch hinzufügen eine unbestimmte Anzahl von Zeilen (gut, begrenzt durch den gesunden Menschenverstand), füllen sie, bequem scrollen die Tabelle selbst, nicht der Rahmen mit ihm. Um die Überschriften an Ort und Stelle zu halten.

Das ist es, was Sie bis jetzt in Arbeit haben. Deshalb sitze ich ruhig auf meinem Hintern und warte. Ich selbst habe es nicht eilig, und ich habe es auch nicht eilig für dich. Ich werde ewig leben. Bis jetzt klappt es.

Verstehe. Nun, dynamische und generierte Tabellen sind für mich und dich notwendig, also werden sie es sein. Ich werde versuchen, alle Aufgaben vor dem neuen Jahr zu erledigen.

[hini]

Wie weit sind wir?

[Реter Konow]

hini #:
Wie weit sind wir gekommen?

Heute wird das Konzept der dynamischen und generierten Tabellen entwickelt, die zusammen mit den wissenschaftlichen Diagrammen funktionieren sollen. Die Aufgabe besteht nicht nur darin, den technischen Teil - Tabellen und Diagramme - zu entwickeln, sondern auch Wege zur "Symbiose" dieser Werkzeuge bei der analytischen Arbeit zu finden.

Hier ist ein Beispiel:

1. Die Daten werden in eine Datei hochgeladen. Spezielle Algorithmen verteilen sie in Tabellen, Zeilen und Spalten.

2. Der Benutzer greift auf die gewünschte Tabelle zu, wählt eine Zeile aus und zeichnet mit einem Doppelklick eine Kurve oder ein Diagramm mit den Zahlen aus dieser Zeile oder Spalte.

3. Der Benutzer wählt die gewünschte Zelle der Tabelle aus und ruft den Aufbau einer neuen Tabelle mit den Daten auf, die mit dem darin befindlichen Parameter verbunden sind.

4. Der Benutzer wechselt von Tabellen zu Diagrammen, von Diagrammen zu Tabellen und Tortendiagrammen, indem er "on the fly" neue Tabellen und Diagramme zusammenstellt oder erzeugt. Durch einfache Klicks und die Eingabe von Parametern in das Fenster kann er die Daten aus verschiedenen "Winkeln" und in verschiedenen Kombinationen innerhalb der erscheinenden grafischen Darstellungen betrachten.

All dies trägt zweifellos zur produktiven Arbeit und zur Suche nach Beziehungen und Mustern in den Daten bei.

Ich habe vor, ein bequemes System der dynamischen Arbeit mit Daten durch Tabellen, Grafiken und Diagramme einzuführen.

Das Wichtigste ist das richtige Konzept. Es braucht die meiste Zeit, um es zu entwickeln. Die technische Umsetzung braucht relativ wenig Zeit.

P.S. Außerdem bereite ich meinen ersten Artikel über den GUI-Builder und die Auszeichnungssprache vor.

P.S.S. Wenn der Artikel veröffentlicht wird, werde ich eine Version für die Codebase vorbereiten, so dass diejenigen, die es wünschen, den Konstruktor herunterladen können.

Im Allgemeinen gibt es eine Menge Arbeit).

[Реter Konow]

Ich werde Ihnen sagen, was meine Pläne sind.

1. Ein Lehrbuch über die Auszeichnungssprache erstellen.

Es ist notwendig, ein komplettes Lehrbuch über die Auszeichnungssprache zu erstellen und es in Teile, Kapitel und Themen zu gliedern.

2. Artikel über Interface Builder und KIB-Sprache schreiben.

Teilen Sie das fertige Lernmaterial in eine Reihe von Artikeln auf und fügen Sie ihnen Codes, Diagramme, Bilder und Gifs hinzu.

3. Eröffnen Sie vor der Veröffentlichung des ersten Artikels einen speziellen Thread mit dem alleinigen Zweck, KIB-Code-Vorlagen zu veröffentlichen. Diejenigen, die es wünschen, können sich eine grafische Benutzeroberfläche (GUI) bauen, indem sie vorgefertigte Teile ausleihen. Sie werden auch in der Lage sein, KIB-Codes hinzuzufügen, wenn sie es wünschen.

4. Bevor der erste Artikel veröffentlicht wird, stellen Sie die neueste Version des Builders in die Codebase ein.

Veröffentlichen Sie auf dieser Seite eine detaillierte Anleitung mit Bildern, Gifs und Videos.

5. Geben Sie am Anfang des Artikels einen Link zum Builder und zur Installationsanleitung und am Ende des Artikels einen Link zum Zweig mit den Vorlagen. So können die Leser sofort nach dem Lesen des Artikels versuchen, eine grafische Oberfläche zu erstellen, indem sie vorgefertigte Fenster oder Elementgruppen ausleihen. Dann werden sie mit dem Gelernten experimentieren und ihre Schnittstellen verbessern.

6. Um den Lesern ein leichtes Verständnis und eine schnelle Beherrschung der Fähigkeiten des Designers zu ermöglichen, ist es meiner Meinung nach notwendig, die Präsentation des Materials zu vereinfachen und die Artikel mit informativen Bildern, lesbaren Schemata und kommentierten Codes zu versehen. Deshalb schreibe ich Artikel nach dem Motto "je einfacher, desto besser" und strebe nach logischer Einfachheit und Klarheit der Bedeutung.

7. Bevor ich den Konstruktor in der Codebase veröffentliche, muss ich noch einige Vorarbeiten leisten:

a) Übersetzen Sie die Namen der Kataloge ins Englische.

b) Vollständige Beseitigung aller Warnungen, die beim Kompilieren des Konstruktors erscheinen (nicht KIB-Code).

c) Behebung einiger zuvor festgestellter Fehler in der Arbeit der Steuerelemente.

d) Einen "Stub" für das Debuggen von Anwendercode, der mit der Engine verbunden ist, einfügen.

Nach der Idee wird die Engine während des Debuggens durch einfaches Auskommentieren ihrer Zeile abgeschaltet, und nur der grafische Kern und die Wrapper-Funktionen aus der Servicedatei "UIDATA.mqh" bleiben verbunden. Alle anderen regulären Funktionen des Konstruktors werden als "leere Funktionen" gesetzt, die als "Stopper" in einer speziellen Datei dienen. Die Zeile in dieser Datei wird vom Benutzer vor dem Debuggen auskommentiert.

Dies ist das Konzept, aber ich habe es noch nicht in der Praxis überprüft.

8. Der erste Artikel wird der schwierigste für mich sein, da ich den gesamten Konstruktor und die Auszeichnungssprache kurz beschreiben muss, um den Lesern eine vollständige Vorstellung von ihrem Zweck, ihren Fähigkeiten und ihrem Gerät zu geben. Außerdem werde ich den Inhalt künftiger Artikel auflisten und ein klares Schema für die künftige Verteilung von Lehrmaterial hinzufügen.

Meiner Meinung nach sind die Artikel Lektionen und daher sollte die Präsentation des Materials pädagogisch sein.

P.S. Ursprünglich beschloss ich, mich auf das Beispiel der bekannten Artikel über grafische Schnittstellen von Anatoly Kozharsky - Easy and Fast library zu stützen. Für mich ist es das vollständigste Ergebnis, das dieses Thema offenbart. Gleichzeitig erkenne ich respektvoll den Beitrag anderer talentierter Autoren an, die würdige Versuche unternommen haben, UI-Bibliotheken vor und nach Anatolys Artikeln zu erstellen. Ich möchte hier besonders Dmitry Fedoseev und Artem Trishkin erwähnen.

Nachdem ich also Anatolys Artikel als Qualitätsstandard und Indikator für Professionalität akzeptiert hatte, "probierte" ich ihr Format an meinem eigenen Material aus und war gezwungen, die Unvereinbarkeit zu erkennen. Die Unterschiede in den Ansätzen und Realisierungen sind zu groß. Daher muss ich meinen eigenen Stil finden und verfeinern, ohne dabei zu vergessen, den hohen schriftstellerischen Standard meiner Vorgänger zu erfüllen.

[Реter Konow]

Der Prozess der Arbeit in der visuellen GUI-Editor auf MT5.

Vor 4 Jahren:

(Klicken Sie auf das Bild).

P.S. Der Kontext der Demonstration ist in dem Beitrag unten beschrieben.

[Реter Konow]

Die Zeit vergeht, und die Idee eines visuellen Editors lebt in meinem Kopf weiter. Sie will mich nicht mehr loslassen. Und wenn ich in aller Ruhe darüber nachdenke, stelle ich mir jedes Mal die Frage: "Wo ist das Problem? - Ich habe ihn doch schon erstellt, er ist nur noch nicht eingeschaltet".

Bei längerem Nachdenken komme ich immer wieder zu den gleichen Schlussfolgerungen: Die Grundfunktionen des visuellen Editors sind in meiner Implementierung bereits vorhanden, es fehlen nur noch komplexe Werkzeuge. Komplexe Dinge können jedoch über die Auszeichnungssprache erstellt werden, was in der Praxis viel schneller und bequemer ist als im visuellen Modus.

Zum Beispiel Tabellen und Baumlisten - es ist langwierig und mühsam, sie manuell zu erstellen, aber sie in KIB-Code zu schreiben ist schnell und einfach... vor allem, wenn man Vorlagen verwendet. vor allem, wenn man Vorlagen verwendet. Warum sollte man sich also die Mühe machen, umständliche visuelle Bearbeitungswerkzeuge für Tabellen und Listen zu erfinden, wenn man sie mit einfachem Kopieren und Einfügen erstellen kann? Das macht keinen Sinn, das ist ziemlich klar. Aber wo liegt dann das Problem?

Das ist ganz einfach. Die Aufgabe besteht darin, die Arbeit der Auszeichnungssprache und die derzeitigen Möglichkeiten des visuellen Editors zu kombinieren. Es ist nicht notwendig, etwas Neues hinzuzufügen, weder zu Ersterem noch zu Letzterem - sie müssen nur so kombiniert werden, dass sie sich gegenseitig ergänzen.

Nachdem ich ernsthaft über dieses Thema nachgedacht habe, bin ich zu dem Schluss gekommen, dass ich selbst dann, wenn sich jetzt die Möglichkeit bietet, vollständig auf die visuelle GUI-Konstruktion umzusteigen, ablehnen würde. Der Grund dafür ist, dass ich nicht die Möglichkeit verlieren möchte, Kib-Code-Vorlagen und einfaches Copy-Paste von Elementen oder Eigenschaften in der Markup-Sprachumgebung zu verwenden. Das ist ein zu wertvoller Vorteil. Vielleicht nicht nur für mich, sondern für alle zukünftigen Benutzer, die ihre Entwicklungen weitergeben oder einfach Teile ihrer früheren Entwicklungen kopieren können. Es ist eine unverzichtbare Sache.

Das heißt, es ist absolut unmöglich, eine Auszeichnungssprache zugunsten eines visuellen Editors aufzugeben. Ich habe es vorher nicht verstanden....

Und so besteht das Problem heute darin, ein System zu entwickeln, das eine harmonische Kombination von Sprache und visuellem Editor ermöglicht. Und eigentlich, technisch gesehen, ist es ziemlich einfach zu machen. (1) Erstens wurden alle notwendigen Funktionen des visuellen Editors bereits vor einigen Jahren geschrieben und getestet, (2) und zweitens wurden in den letzten Monaten die Schlüsselmechanismen der Auszeichnungssprache gut gestrafft und ein großes Upgrade mit der Hinzufügung der Software-Schnittstellenverwaltung durchgeführt. Mit anderen Worten, alles ist bereit für die Integration und Verschmelzung, und die Aufgabe besteht nur noch darin, das Konzept der konfliktfreien Interaktion beider Funktionalitäten im Prozess der Modellierung und des Aufbaus einer grafischen Schnittstelle zu durchdenken.

Konzeptionell stehen Auszeichnungssprache und visueller Editor WIRKLICH im Konflikt.

Es gibt mehrere Gründe, die diese Aufgabe schwierig machen:

Erinnern Sie sich daran, dass GUI-Elemente und Fenster standardmäßig in Code geschrieben werden, aber auch in einem visuellen Editor erstellt werden können, wie im obigen Bild gezeigt.

1) Sowohl im ersten als auch im zweiten Fall bildet die Funktionalität des Konstruktors den grafischen Kern, wenn auch auf unterschiedliche Art und Weise, aber da die Fähigkeiten des visuellen Editors schwächer sind als die der Sprache, akzeptieren die erstellten Elemente keinen vollständigen Satz von Einstellungen durch den Benutzer über den Editor. Einstellungen können durch das Schreiben eines Editors ergänzt werden, aber dann wird die Auszeichnungssprache überflüssig, und das ist schlecht, weil es keine Möglichkeit gibt, sich auf Code-Vorlagen zu verlassen. Man kann die Auszeichnungssprache nicht aufgeben, Punkt.

2) Wenn neue Elemente und Fenster im visuellen Modus erstellt werden, "sieht" die Auszeichnungssprache sie nicht. Das heißt, die Auszeichnungssprache wird während des visuellen Aufbaus der GUI nicht aktualisiert. Dem ursprünglichen KIB-Code wird nichts "hinzugefügt". Diese Tatsache führt wiederum zu einer konzeptionellen Trennung zwischen dem visuellen Editor und der Auszeichnungssprache. Das ist ein Konflikt.

Wie soll man sich in dieser Situation verhalten und was soll man tun? Wie sieht der Kompromiss aus, der zu einer Symbiose zweier leistungsstarker GUI-Werkzeuge führt?

Ich werde versuchen, die Lösung zu verstehen:

Hauptpunkt: Begrenzung der Rolle des visuellen Editors bei der Modellierung der Schnittstelle, wobei die Sprachfunktionen unverändert bleiben. Praktisch bedeutet dies:

1. Weigern Sie sich, neue Elemente und Fenster im visuellen Modus zu erstellen, da der Markup-Code beim Hinzufügen dieser Elemente nicht aktualisiert wird.

2. Belassen Sie die Möglichkeit, Positionen und Eigenschaften von Elementen und Fenstern der Benutzer-GUI über die Einstellungsfenster des visuellen Editors zu bearbeiten, zusätzlich zu den Standard- und benutzerdefinierten Werten des Benutzers im KIB-Code. In diesem Fall schreibt und speichert der Editor eine spezielle Datei mit überschriebenen Werten, aus der er sie in den Kernel lädt und den Elementen zuweist. In der Tat bedeutet dies eine neue Art von Elementvorlagen, die im Editor "verarbeitet" werden. Sie kollidieren nicht mit den Kib-Code-Vorlagen, sondern überschreiben nur die in ihnen festgelegten Eigenschaftswerte.

Dies ist meiner Meinung nach eine effektive Symbiose zwischen Editor und Auszeichnungssprache.

P.S. Die Ironie ist, dass es technisch möglich ist, die Idee der Verschmelzung von Editor und Sprachfunktionen in ein paar Tagen zu realisieren, und es ist durchaus realistisch, aber alle Details ihrer Integration und Interaktion in der Arbeit des Benutzers zu durchdenken.... das braucht mehr Zeit. :)

P.S. Aber die wichtigste Schlussfolgerung ist, dass sie zusammenarbeiten KÖNNEN und sollten, indem sie sich gegenseitig ergänzen.