Mein Ansatz. Der Kern ist der Motor. - Seite 26
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
GUI-Konstruktoren werden für eine bestimmte Grafikbibliothek erstellt. Wenn es einen GUI-Builder für MQL gäbe, wäre er hier zu finden.
Ich habe einen Artikel irgendwo gesehen, irgendwo in Hubre, es scheint, wie "erstellen Sie einen GUI-Konstruktor für Python", so dass ich dachte, dass vielleicht jemand eine Multiplattform-GUI gesehen hat, wo ich meinen eigenen Code hinzufügen könnte
Aber wenn ich einen Konstruktor von Grund auf neu schreiben will, würde ich lieber MQL verwenden.
1. ich habe es nie in Sharp entwickelt, ich hatte kein Interesse, aber vor etwa 5 Jahren habe ich Delphi benutzt, um .dll mit Schaltflächen und Formularen zu verbinden, und es hat ohne Probleme funktioniert, sogar das ganze Delphi-Projekt war an einem Tag fertig, ich habe sogar einen halben Tag damit verbracht, den Grund zu finden, warum die Standardformulare nicht funktionierten, aber als ich es durch Aufrufen von Systemfenstern verbunden habe, hat alles richtig funktioniert, aber MT4 war damals sehr langsam, jetzt hinkt es, es fliegt
Ich habe keine Probleme zu verbinden .dll, synchronisieren mit Standard-Mutexe - starten Sie einen Thread, um eine Verbindung zum Terminal und das ist alles, dann geht alles von selbst - separat ein Formular in .dll, separat MT niemand wartet auf jemanden
SZS: bitte beachten Sie, dass Delphi eher unpraktisch ist, um eine .dll zu erstellen, aber was zur Hand war (was ich zu dem Zeitpunkt hatte), habe ich benutzt)))
2. aber was das Wesentliche angeht, verstehe ich nicht, warum sie nicht Standardklassen aus dem MT-Toolkit verwenden können, es wäre cool, den Prozess der Grafikerstellung zu vereinheitlichen, vielleicht wäre es ein universelles Include, in dem man unnötige Schaltflächen/Dialoge usw. kommentieren könnte.
1. Dies ist eine sehr, sehr laienhafte Art, das Problem zu betrachten (nichts für ungut). Ein Projekt, das an einem Tag erledigt ist, ist kein Projekt. Es ist eine kleine Aufgabe.
Stellen Sie sich vor, Sie erstellen eine Anwendung, die aus 10 Fenstern besteht, darunter große Datentabellen, Einstellungsfenster und Dialogfelder. Sie zeichnen sie in Delphi. Dann erstellen Sie eine DLL. Dann verbinden Sie es mit Ihrem MT-Projekt.
Ihre MT-Anwendung muss sich über Shared Memory mit der Delphi-GUI verbinden. Verbinden Sie Funktionen mit Steuerelementen und Daten mit Tabellenzellen. Sie müssen das komplexe Zusammenspiel der beiden Teile der Anwendung organisieren und gut durchdenken.
Sie benötigen den synchronen Betrieb und den Austausch von Parameterwerten zwischen den beiden Teilen - GUI und MT Application.
Noch einmal: Wenn Ihre Anwendung groß und ernst ist (Tabellen, Einstellungsfenster, Dialogfelder, alte Listen, etc...), ist die Erstellung einer einzigen, kohärenten und effizienten Arbeit von zwei Teilen über DLL eine SEHR ernste Aufgabe. Ich habe es getan, und ich weiß, wovon ich spreche.
Und Sie sprechen von einer kleinen Aufgabe, die an einem Tag erledigt werden kann. Es ist nichts Ernstes.
Sie können die Standardbibliothek schon seit langem verwenden. Die Frage ist jedoch, wie hoch der Aufwand ist und welches Ergebnis Sie erzielen werden. Was sind sie? Ich weiß, dass Anatoly die Standardbibliothek als Sprungbrett für die Erstellung seiner eigenen Bibliothek verwendet hat. Aber warum hat er das getan, wenn die Standardbibliothek auch funktioniert? Die Antwort ist einfach - er implementierte alles in höherer Qualität und ging über die Standardbibliothek hinaus. Eine massenhafte Verbreitung kann jedoch nur erreicht werden, wenn die Schwierigkeit der Nutzung verringert wird. Je einfacher die Nutzung, desto mehr Nutzer werden es sein (natürlich mit einer Steigerung der Qualität).
1. Dies ist eine sehr, sehr laienhafte Art, das Problem zu betrachten (nichts für ungut). Ein Projekt, das an einem Tag erledigt ist, ist kein Projekt. Es ist eine kleine Aufgabe.
Stellen Sie sich vor, Sie erstellen eine Anwendung, die aus 10 Fenstern besteht, darunter große Datentabellen, Einstellungsfenster und Dialogfelder. Sie zeichnen sie in Delphi. Dann erstellen Sie eine DLL. Dann verbinden Sie es mit Ihrem MT-Projekt.
Ihre MT-Anwendung muss über Shared Memory mit der Delphi-GUI verbunden sein. Verbinden Sie Funktionen mit Steuerelementen und Daten mit Tabellenzellen. Sie müssen das komplexe Zusammenspiel der beiden Teile der Anwendung organisieren und gut durchdenken.
Sie benötigen den synchronen Betrieb und den Austausch von Parameterwerten zwischen den beiden Teilen - GUI und MT Application.
Noch einmal: Wenn Ihre Anwendung groß und ernst ist (Tabellen, Einstellungsfenster, Dialogfelder, alte Listen, etc...), ist die Erstellung einer einzigen, kohärenten und effizienten Arbeit von zwei Teilen über DLL eine SEHR ernste Aufgabe. Ich habe es getan, und ich weiß, wovon ich spreche.
Und Sie sprechen von einer kleinen Aufgabe, die an einem Tag erledigt werden kann. Das ist nicht ernst gemeint.
Worüber beschweren Sie sich? Sie verstehen einfach nicht, dass der Datenaustausch zwischen MT und .dll so alt ist wie die Welt.
Ich habe eine .dll erstellt, weil es bisher keine anständigen Grafiken in MT gab, ich wollte Buttons und ein Panel
Tische? - gut Tabellen zeichnen, Kontrollen? - zeichnen.... Man kann die Aufgabe einfach nicht trennen, denn in Delphi gibt es viele fertige Komponenten, sowohl für die Erstellung von Datenbanken als auch für die Arbeit mit ihnen
D.h. von MT benötigen Sie nur die Daten selbst, und der Rest wird ein Drittanbieter-Programm zu tun, können Sie Ihr Wort für sie, aber in der gleichen Delphi zu schreiben Arbeit mit der Datenbank, mit der Ausgabe in Tabellen, Diagramme, etc. arbeiten für einen Tag ;)
Was sind Daten in MT? = Es ist nur ein Häkchen und ein Balken, und es macht keinen Sinn, durch eine .dll zu "rasen" - einfach alles einmal in eine Datei packen und mit der Datei in einem Drittanbieterprogramm arbeiten.
SZS: Jemand schrieb kürzlich im Forum, dass moderne IT-Unternehmen Mitarbeiter schätzen, die den Code, in dem sie arbeiten, nicht gründlich verstehen, sondern diejenigen, die so schnell wie möglich ein großes Volumen an Aufgaben ausführen können, d.h. in der Lage sein müssen, die Arbeit anderer Leute in ihre Aufgabe zu integrieren, und nicht jedes Mal von Grund auf neu zu bauen! Ich weiß nicht, Ihre Hauptbeschäftigung, ich habe nie als Programmierer gearbeitet, aber ich bin ständig in verwandten Bereichen arbeiten, für eine lange Zeit in der Wartung von industriellen Steuerungen, ACS und ACS beschäftigt, und hatte zu tun, fügen Sie Programm-Lösungen und die Interaktion mit den Entwicklern, so musste ich in alle vorgefertigten Software-Lösungen zu bekommen - hier kann man nicht alles von Grund auf neu schreiben )))), und die Hersteller von industriellen "Eisen" verwenden spezialisierte Programmiersysteme, wo C, wo SCADA, und Assembler, und jeder einmal muss in der Lage sein, jemand anderes Code zu lesen ;))
Sie schlagen vor, auf der Grundlage Ihres "Motors" ein bedingt funktionsfähiges Design zu schaffen, das von Programmierern nicht weiter verändert werden kann?
Wo liegen die Schwierigkeiten? Sie verstehen einfach nicht, dass der Datenaustausch zwischen MT und .dll so alt ist wie die Welt.
Ich habe die .dll gemacht, weil es vorher keine anständigen Grafiken in MT gab, ich wollte Buttons und Panel
Tische? - gut Tabellen zeichnen, Kontrollen? - zeichnen.... Man kann die Aufgabe einfach nicht trennen, denn in Delphi gibt es viele fertige Komponenten, sowohl für die Erstellung von Datenbanken als auch für die Arbeit mit ihnen
D.h. von MT müssen Sie nur die Daten, und der Rest wird ein Drittanbieter-Programm zu tun, können Sie Ihr Wort für sie, aber in der gleichen Delphi zu schreiben, die Arbeit mit der Datenbank, mit der Ausgabe in Tabellen, Diagramme, usw. Arbeit für einen Tag ;)
ZS: Was sind Daten in MT? = Es handelt sich nur um ein Häkchen und einen Balken, und es macht keinen Sinn, den Verlauf durch eine .dll zu "jagen" - packen Sie einfach alles einmal in eine Datei und arbeiten Sie mit dieser Datei in einem Drittanbieterprogramm.
Wenn Sie nur die Daten nehmen, die von MT kommen, und sie durch eine DLL an eine Anwendung weitergeben, die in Delphi oder C++ oder C# geschrieben ist, dann ist es definitiv möglich. Dann wird die Handelsanwendung komplett in einer anderen Programmiersprache geschrieben.
Das heißt, Zeitreihen, Tester, Optimierung, Synthetik und viele andere Dinge müssen in einer anderen Sprache erstellt werden.
Warum brauchen Sie MQL überhaupt? Es genügt, die Daten direkt an eine Drittanwendung zu liefern und die Plattform als Absender von Ereignissen und Bestellungen zu nutzen. Und das ist alles. Aber die Vorteile von MQL als Handelssystemsprache gehen dabei verloren.
Warum brauchen Sie MQL?
Denn MQL ist eine Anwendungssprache, die für das Schreiben von Handelsanwendungen entwickelt wurde. Dies ist sein Hauptvorteil. Es ist leicht und einfach. Es bietet eine Menge fertiger Lösungen für Programmierer. Sie nehmen sie und benutzen sie.
Programmierer haben die Wahl:
Offensichtlich ist die bevorzugte Option, MQL und MT zu verwenden, weil sie Vorteile bieten - Testen, Optimierung, Forschung (Synthetik), Indikatoren, praktische Funktionen, Zeitreihen... + Technische Sprachunterstützung im Forum.
Dieses Ideal hat jedoch einen schwerwiegenden Nachteil: Es ist nur begrenzt möglich, komplexe Anwendungen zu erstellen, da es schwierig ist, eine hochwertige grafische Benutzeroberfläche zu entwickeln.
Dieses letzte Problem habe ich weitgehend gelöst.
Wenn Sie also in die Praxis gehen und eine ernsthafte Bewerbung schreiben, werden Sie sich sicher für MT entscheiden. Das gilt auch für viele, viele andere.
...
Schlagen Sie vor, auf der Grundlage Ihres "Motors" einen bedingt funktionsfähigen Entwurf zu erstellen, der von Programmierern nicht weiter verändert werden kann?
Die Engine ist der "Träger" dieser GUI, die in meinem Konstruktor erstellt wird. Sie braucht nicht geändert zu werden. Verbinden Sie es nur mit der Anwendung und die erstellte GUI wird funktionieren.
Noch einmal: wenn die Anwendung groß und seriös ist (Tabellen, Einstellungsfenster, Dialoge, alte Listen, etc...), ist das Erstellen eines einzigen, kohärenten und effizienten Betriebs der beiden Teile über die DLL eine SEHR ernste Aufgabe. Ich habe es getan, und ich weiß, wovon ich spreche.
Wer eine große und komplexe Anwendung erstellen kann, wird die Gui-Bibliothek auf jeden Fall nutzen. Was sollte der Entwickler tun, wenn er seine Anwendung entwickelt und beschließt, z. B. Animationen hinzuzufügen? Sollte er Sie aufsuchen und fragen, oder sollte er alles abbrechen und von Grund auf neu aufbauen?
Wie kommen Sie auf die Idee, dass es ein Problem bei der Erstellung der grafischen Benutzeroberfläche gibt? Schauen Sie sich auf dem Markt um, es gibt viele Anwendungen mit GUI.
1. Wer eine große und komplexe Anwendung erstellen kann, wird die Gui-Bibliothek auf jeden Fall nutzen.
2. Was soll der Entwickler tun, wenn er bei der Entwicklung seiner Anwendung beschließt, zum Beispiel eine Animation hinzuzufügen? Sie suchen und fragen, oder alles kaputt machen und von Grund auf neu bauen?
3) Und wie kommen Sie auf die Idee, dass es ein Problem mit der Erstellung von GUIs gibt? Schauen Sie sich auf dem Marktplatz um, dort gibt es viele Anwendungen mit grafischen Oberflächen.
1. Die GUI-Bibliothek ist eine Bibliothek für ernsthafte Programmierer. Wegen der Schwierigkeit der Anwendung kann es nicht in Massenproduktion hergestellt werden. Welchen Sinn hat das? Nur einige von uns werden die Bibliothek durchforsten und komplexe Anwendungen erstellen, während andere dazu nicht in der Lage sein werden?
2. Lassen Sie den Entwickler Animationen in seiner Anwendung erstellen. Was hat das mit mir zu tun? Er kann diese Animation unabhängig von der GUI und der Engine aufrufen, oder den Aufruf seiner Animation mit einem Button verknüpfen.
3) Es gibt nur wenige Leute, deren GUI es wert ist, beachtet zu werden. Du, Anatoly und vielleicht noch jemand... Der Rest erreicht nicht das geringste ernsthafte Niveau.
3. Es gibt nur wenige Leute, deren GUI bemerkenswert ist.
Ich würde nicht so kategorisch vorgehen. Und ich habe nicht über die Entwicklung von GUI-Bibliotheken gesprochen, sondern über GUI-Anwendungen. Es gibt viele davon auf dem Markt, einige verwenden ihre eigenen Entwicklungen, einige die Standardbibliothek und einige die Bibliothek von Anatoly.
1. Das ist der Punkt: Die GUI-Bibliothek ist für ernsthafte Programmierer gedacht. Wegen der Schwierigkeit der Anwendung kann es nicht massenhaft verbreitet werden. Welchen Sinn hat das? Einige von ihnen werden die Bibliothek durchforsten und komplexe Anwendungen erstellen, andere werden dazu nicht in der Lage sein?
2. Lassen Sie den Entwickler Animationen in seiner Anwendung erstellen. Was hat das mit mir zu tun? Er kann diese Animation unabhängig von der GUI und der Engine aufrufen, oder den Aufruf seiner Animation mit einer Schaltfläche verknüpfen.
3) Es gibt nur wenige Leute, deren GUI es wert ist, beachtet zu werden. Du, Anatoly und vielleicht noch jemand... Die übrigen erreichen nicht einmal das geringste ernsthafte Niveau.
Peter, ich glaube, das Hauptproblem, das Sie haben, liegt in der Positionierung des Projekts.
Es ist vielleicht nur für diejenigen Teilnehmer interessant, die über eine recht gute Erfahrung im Programmieren verfügen, aber gleichzeitig - lieber die Hände wechseln.
Glauben Sie, dass es viele von ihnen gibt?
Sehen Sie - alle Kritiker Ihres Entwurfs sind Menschen, die nicht regelmäßig "manuell" handeln. Höchstens - von Zeit zu Zeit. Und da sie Ihr Projekt nicht als "manuelle" Händler betrachten, sondern als Programmierer. Und verständlicherweise finden sie eine Menge sehr zweifelhafter Lösungen.
Meiner Meinung nach sollte sich Ihre Frage jetzt darauf beziehen, diese (meiner Meinung nach sehr enge) Nische zu finden: Programmierer, die lieber die Hände wechseln.
Ich glaube, ich sah einen Artikel irgendwo, wie auf hubra, genannt "Erstellen einer GUI-Builder für Python", so dass ich dachte, vielleicht hat jemand eine Multiplattform-GUI gesehen, wo ich meinen eigenen Code hinzufügen könnte
Wenn ich einen Konstruktor von Grund auf neu schreiben möchte, würde ich lieber MQL verwenden.
Moderne GUI-Konstruktoren (die, die "Schaltflächen auf Formulare verteilen") sind eine ziemliche technische Angelegenheit, und MQL-Elemente an sie anzuhängen, sieht nicht gerade fantastisch aus.
In der Zwischenform (Projektdatei usw.) haben fast alle von ihnen XML, das das Layout und die Beziehungen zwischen den Elementen beschreibt.
Die Codegenerierung für die Zielplattform ist in Wirklichkeit eine XSLT-Transformation, die von jedem durchgeführt werden kann, der sich für einen Webentwickler hält :-)
Nehmen Sie zum Beispiel EasyAndFast (https://www.mql5.com/ru/code/19703), denn es ist objektbasiert und hat alle notwendigen Komponenten. (und übrigens offen und dokumentiert, anders als in diesem Thread),
und schreiben Sie einfach einen Übersetzer.
Es gibt keine gui-mql Builder, nicht weil es mega-komplex ist, sondern weil es einfach nicht gefragt ist.