Galerie der in MQL geschriebenen UIs - Seite 74

Neuer Kommentar
 
Ungefährer Zeitraum der Veröffentlichung: 22. bis 28. November.

P.S. Bitte berücksichtigen Sie den großen Arbeitsaufwand. Ich danke Ihnen.
 
Реter Konow #:
Voraussichtlicher Veröffentlichungszeitraum: zwischen dem 22. und 28. November.

P.S. Bitte berücksichtigen Sie den großen Arbeitsaufwand. Ich danke Ihnen.

Ich wäre gerne ein Beta-Tester :)

 

... Apropos Inhalt (für "zukünftige Ideen") :

Ich "versuche" mich gerade an der Gestaltung eines Panels direkt aus Terminal Objects: Button und Text Label,

und bin dabei auf folgende Situation gestoßen: -->

--> für "mich" - um Verwirrung bei Buttons zu vermeiden - habe ich beschlossen, den Button selbst "detailliert" zu signieren.
und dementsprechend - war es notwendig, die Beschriftung nicht in der Schaltfläche selbst zu machen (da die Beschriftung in der Mitte der Höhe der Schaltfläche sein wird), sondern in Form von "überlagerndem" Text auf der Schaltfläche (!), weshalb die Beschriftung 2-zeilig ausfiel:

daher der Grund, diese Situation zu äußern - für den Fall, dass Sie in Zukunft einen Weg "erfinden" - WIE man solche 2-3 zeiligen Beschriftungen auf Schaltflächen in Ihrer GUI machen kann --> ohne oder mit Kanvas --

 
Vitaliy Kostrubko #:

Ich würde gerne ein Beta-Tester sein :)

Vielen Dank für diese Initiative!

Es wird definitiv dazu beitragen, die Qualität der technischen Umsetzung zu verbessern. Aber ich muss sofort sagen, dass der Code des Konstruktors oder des Editors nicht zur Diskussion steht. Es geht nur um die Funktionalität und die Übereinstimmung mit den Benutzeranforderungen. Dies ist eine Voraussetzung. Wenn Sie zustimmen, wird alles "auf Schienen" gehen. :)
 
Vitaliy Kostrubko #:

... WIE Sie ähnliche 2-3 zeilige Beschriftungen auf Schaltflächen in Ihrer GUI erstellen können --> ohne Kanvas oder MIT Kanvas

Wird.
 
Es wurde eine wohlüberlegte strategische Entscheidung getroffen, sich ganz auf die Wiederherstellung der Funktionalität des visuellen Editors zu konzentrieren. Nach groben Schätzungen wird er in den nächsten 3 Wochen minimal vollständig und praktisch anwendbar sein können. Weiter nur Entwicklung und Verbesserung.

Ich werde die Gründe für diese Entscheidung weiter erläutern.
 
Vitaliy Kostrubko #:

... Apropos Inhalt (für "Ideen für die Zukunft") :

Ich "versuche" mich gerade an der Gestaltung eines Panels direkt aus Terminal-Objekten: Button und Text Label,

und bin dabei auf folgende Situation gestoßen : -->


--> Für "mich" - um Verwechslungen bei Buttons zu vermeiden - beschloss ich, den Button "Detail" selbst zu beschriften.
und dementsprechend - war es notwendig, die Inschrift nicht in der Schaltfläche selbst zu machen (wie die Inschrift in der Mitte der Schaltfläche Höhe erscheinen wird), aber in Form von "überlagert" Text auf der Schaltfläche (!). Das ist, warum die Inschrift stellte sich heraus, 2-zeilig sein:

daher die Prämisse, diese Situation zu äußern - für den Fall, dass Sie in der Zukunft einen Weg "erfinden" - WIE man solche 2-3 zeiligen Beschriftungen auf Schaltflächen in Ihrer GUI machen kann --> ohne oder mit Kanvas --

oder? :-)

ohne GUI-Editoren :-)

oder so...

oder so.

:-)

nur fürs Protokoll und ich hatte 10 Minuten Zeit...

 
Warum es keinen Sinn macht, die Richtung der Auszeichnungssprache weiterzuentwickeln:

1. Hohe Einstiegsschwelle.

Um komplexe Panels erstellen zu können, müssen die Benutzer die Regeln der Sprache kennen. Aber sie werden sie erst nach dem Studium von ~20 Tutorials kennen, die ich in den nächsten 6-7 Monaten schreiben muss.

2. Es ist unmöglich, GUI-Vorlagen ohne Kenntnis der Sprachregeln vollständig zu nutzen.

Das Wissen wird in Tutorien vermittelt, und die Materialien werden in Artikeln abgedruckt. Die Artikel werden in Abständen von ein oder zwei pro Monat veröffentlicht. Um einen vollständigen Studiengang zu absolvieren, müssen mindestens 7 bis 10 Artikel veröffentlicht werden, und bei diesem Tempo wird der Prozess etwa ein halbes Jahr dauern.

Die Schlussfolgerung aus den obigen Argumenten ist, dass es sinnvoll ist, Vorlagen erst nach der Veröffentlichung von Artikeln zu veröffentlichen. Ohne praktische Kenntnisse der Sprache werden die Benutzer nicht in der Lage sein, die kib-Code-Vorlagen an ihre Bedürfnisse anzupassen, was ihren Nutzen erheblich schmälern wird. Infolgedessen werden sich die Benutzer an mich wenden, um Erklärungen und Hilfe zu erhalten. Ich kann ein oder zwei Personen helfen, aber wenn es mehr sind, befinden wir uns in einer Sackgasse.




Nun, warum es sehr sinnvoll ist, einen visuellen Editor zu entwickeln.

1. Niedrige Einstiegsschwelle für Benutzer.

Der visuelle Editor hat den Vorteil, dass er intuitiv ist. Seine Möglichkeiten und Grenzen lassen sich leicht erkennen, wenn man seine grafische Oberfläche erkundet. Das Hinzufügen von Tooltips hilft, komplexe Zusammenhänge zu verstehen.

2. Geringer Umfang des erforderlichen Schulungsmaterials für den Einstieg in den visuellen Editor.

Der gesamte Kurs kann in 3 - 5 Artikeln untergebracht werden. Aber auch ohne sie werden die Benutzer schnell lernen, wie man einfache und komplexe Panels erstellt.

3. Der Editor vereinfacht und beschleunigt die GUI-Erstellung so weit wie möglich.

Der Unterschied zwischen dem Aufwand für die Arbeit mit einer Auszeichnungssprache und einem visuellen Editor ist enorm. Dieser Faktor gab schließlich den Ausschlag zugunsten des visuellen Editors. Der geringe Aufwand wirkt sich positiv auf das Interesse der Anwender aus, GUI-Handelsanwendungen zu erstellen.

4. Die konzeptionelle Basis des visuellen Editors ist gut durchdacht, und die technische Basis wurde vor 4 Jahren geschrieben und getestet. Wir können sagen, dass der Editor objektiv an der Schwelle zu seiner ersten Veröffentlichung steht.
 
Maxim Kuznetsov #:

oder? :-)

das ist ohne GUI-Editoren :-)

oder so.

oder so

:-)

Ich meine ja nur, und ich hatte 10 Minuten Zeit...

Natürlich wird es Leute geben, die Programme von Drittanbietern verwenden wollen, um eine GUI zu erstellen und sie über DLLs zu verbinden, das ist in Ordnung.

Das bleibt jedem selbst überlassen.
 
Реter Konow #:
...
4. Die konzeptionelle Basis des vis.editor ist gut durchdacht, und die technische Basis wurde vor 4 Jahren geschrieben und getestet. Wir können sagen, dass der Editor an der Schwelle zu seiner ersten Veröffentlichung steht.
Dieser Punkt ist es wert, im Detail erläutert zu werden.

Der visuelle Editor (VE) erfordert ein Minimum an notwendiger Funktionalität, um implementiert zu werden. Betrachten wir einmal ganz allgemein, was das ist.

Funktionelle Basis des VE:

1. die Interaktion von editierbaren und bearbeitbaren Elementen.

2. Trennung des grafischen Kerns in einen Mitarbeiter- und einen Benutzerbereich. Editierende und editierbare Elemente sollten sich in verschiedenen Teilen des Kerns befinden, erstere im Personalbereich, letztere im Benutzerbereich.

3. Die Funktionen zum Erstellen und Löschen von Elementen und Fenstern sollten im Benutzerbereich des Kerns arbeiten und von Elementen aus dem Standardbereich aufgerufen werden.

4. Funktionalität zum Speichern des benutzerdefinierten Teils des Kernels nach der GUI-Bearbeitung.

5. Laden des gespeicherten Teils des Kernels (Projekts) aus einer Datei, um das Projekt neu zu gestalten und zu verfeinern.


Dies ist das notwendige Minimum für einen funktionierenden Editor.


Was bereits implementiert ist:

1. Interaktion von Editoren und editierbaren Elementen.

Editoren haben zwei spezifische Eigenschaften: Target_object und Target_property. Wenn der Benutzer auf ein editierbares Element klickt, erhält es einen speziellen Fokus. In diesem Moment übernehmen die Editorelemente die Eigenschaftswerte des editierbaren Elements in ihre Parameter gemäß ihrer Eigenschaft Target_property und geben sie über ihre andere spezielle Eigenschaft Output_property aus. Das heißt, wenn Target_property die Farbe des Elements ist, dann kann Output_property entweder ein Text sein, der den Namen der Farbe des bearbeitbaren Elements anzeigt, oder die Grundfarbe des Editorelements, die sich entsprechend ändert.

Es gibt viele Varianten der Verknüpfung dieser Elemente, aber die technische Umsetzung ist nicht schwierig und recht einfach.

2- Der Konstruktor hat jetzt seine eigene interne API-Datei, die es einfach macht, die Funktionalität seiner eigenen Anpassungsfenster mit Hilfe von Wrapper-Funktionen und eingehenden GUI-Ereignissen zu nutzen.

3) Außerdem kann der Konstruktor auf zwei Arten geladen werden: direkt aus dem Kernel, unter Umgehung der Kib-Code-Interpretation, oder standardmäßig über die Kib-Code-Interpretation. Dadurch ist die Ladezeit des Konstruktors auf der Karte von ~1,5 Sekunden auf ~16 bis 32 Millisekunden gesunken. Außerdem konnten wir dank des Ladens aus der Kernel-Datei die Warnungen im Zusammenhang mit kib-Code loswerden. Aber vielleicht ist das nur eine Kleinigkeit im Vergleich zu den Aussichten. Der Hauptvorteil des Ladens aus einem fertigen Kernel ist die Möglichkeit, fertige Kernelteile aus anderen Dateien zu "toppen", die Vorlagen für Fenster oder Gruppen von Elementen sein können, die für die Arbeit des Benutzers notwendig sind. Dies ist ein Schritt in die richtige Richtung.

4. Die Ordner und Dateien des Konstruktors sind vollständig ins Englische übersetzt. Die Architektur hat sich stark verändert.

Mein Hauptziel ist es, die minimale Funktionalität des Editors zu schaffen, die es erlaubt, den Editor von innen nach außen zu bauen, unter Umgehung der Auszeichnungssprache.

1...676869707172737475767778798081...83
Neuer Kommentar