Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 13

Neuer Kommentar
 
Igor Volodin:


Für mich ist es einfacher, ein Produktentwicklungsteam zu gründen, dessen Mitglieder zu einem vereinbarten Grad einen Gewinn aus dem Produktverkauf erhalten (vielleicht ist jemand der Projektideologe, jemand finanziert einen Anteil, jemand ist der Programmierer).

Und da jeder finanziell motiviert ist, auch die notwendigen Bibliotheken für die Schnittstelle als Teil des Projekts zu implementieren.

zugestimmt, aber die Bibliothek selbst sollte von der Allgemeinheit finanziert werden)
 
o_O:
Igor Wolodin:


Für mich ist es einfacher, ein Produktentwicklungsteam zu bilden, dessen Mitglieder in einem vereinbarten Umfang einen Gewinn aus dem Produktverkauf erhalten (vielleicht ist jemand der Projektideologe, jemand finanziert einen Anteil, jemand ist der Programmierer).

Und da alle finanziell motiviert sind - im Rahmen des Projekts die notwendigen Bibliotheken für die Schnittstelle zu implementieren.

Ich stimme zu, aber die Bibliothek selbst sollte Open-Source-Crowdsourced sein).
Ich habe den Thread gelesen und nicht verstanden, was für es notwendig ist - die Schaltfläche auf Canvas von Grund auf zu zeichnen. Können Sie das ohne Emotionen erklären?
 
Alexey Volchanskiy:
Ich habe den Thread gelesen und verstehe immer noch nicht, warum es notwendig ist, eine Schaltfläche auf Canvas von Grund auf zu zeichnen. Können Sie das ohne Emotionen erklären?
Ich wähle zwischen ObjectCreate und ResourceCreate.
weil MT-Entwickler nicht allmächtig sind und es zeitaufwendig ist, sie mit belanglosen Anfragen zu belästigen
 

Warum das nützlich sein könnte:

1. die Schnittstelle auf der Bitmap ist schnell. Sie ist so schnell, dass sie vom System kaum zu unterscheiden ist. Ich habe zum Beispiel halbtransparente Elemente mit Farbverläufen implementiert, undselbst wenn sie sich bewegen, werden sie ohne sichtbare Verzögerung gerendert, wobei die Farbmischung und die Alphakanalberechnung bei anderen Objekten mit halbtransparenten Farbverläufen berücksichtigt werden.

2. Die Schnittstelle ist skalierbar. Sie können die Anwendung komplexer gestalten und sie wird nicht durch das Löschen und Erstellen einer großen Anzahl von Diagrammobjekten verlangsamt. Die Kosten für das Neuzeichnen sind minimal, es handelt sich lediglich um den Austausch eines Bildes in einer Tausendstelsekunde.

3. Es können sowohl vorgefertigte Steuerelemente als auch neue Steuerelemente erstellt werden, da Sie z. B. Ihren eigenen Ereignispool bereitstellen können:

OnMouseDown - drückt die LKM

OnMouseUp - drückt die LKM

OnMouseHoverOn - Bewegt den Mauszeiger über ein Objekt

OnMouseHoverOut - bewegt den Mauszeiger vom Objekt weg

OnMouseClick - Drücken und Klicken innerhalb der Objektgrenzen

OnMouseDblClick - doppelter Mausklick innerhalb der Grenzen des Objekts

OnDragStart - Ereignis, das einmal zu Beginn der Bewegung mit gedrückter linker Maustaste auftritt

OnDragMove - Ereignis, das bei der Bewegung mit der linken Maustaste erzeugt wird

OnDragEnd - Ereignis, das nach dem Verschieben mit LKM erzeugt wird

OnPut - Objekt wird in ein anderes Objekt umgewandelt

OnGet - das Objekt wird in ein anderes Objekt umgewandelt

OnFocus - Objekt hat den Fokus erhalten

OnBlur - Objekt verliert den Fokus

OnResize - Objekt hat Größe geändert

OnParentResize - das übergeordnete Objekt hat seine Größe geändert

OnKeyPress - eine gedrückte Taste

OnChange - Wert eines Feldes geändert

usw.

 
Igor Volodin:

Warum das nützlich sein könnte:

1. die Schnittstelle auf der Bitmap ist schnell. Sie ist so schnell, dass sie von der Systemschnittstelle praktisch nicht zu unterscheiden ist. Ich habe zum Beispiel halbtransparente Elemente mit Farbverläufen implementiert, undselbst wenn sie sich bewegen, werden sie ohne sichtbare Verzögerung gerendert, wobei die Farbmischung und die Alphakanalberechnung bei anderen Objekten mit halbtransparenten Farbverläufen berücksichtigt werden.

2. Die Schnittstelle ist skalierbar. Sie können die Anwendung komplexer gestalten und sie wird nicht durch das Löschen und Erstellen einer großen Anzahl von Diagrammobjekten verlangsamt. Die Kosten für das Neuzeichnen sind minimal, es handelt sich nur um einen Austausch des Bildes in einer Tausendstelsekunde.

3. Es können sowohl vorgefertigte Steuerelemente als auch neue Steuerelemente erstellt werden, da Sie z. B. Ihren eigenen Ereignispool bereitstellen können:

OnMouseDown - drückt die LKM

OnMouseUp - drückt die LKM

OnMouseHoverOn - Bewegt den Mauszeiger über ein Objekt

OnMouseHoverOut - bewegt den Mauszeiger vom Objekt weg

OnMouseClick - Drücken und Klicken innerhalb der Objektgrenzen

OnMouseDblClick - doppelter Mausklick innerhalb der Grenzen des Objekts

OnDragStart - Ereignis, das einmal zu Beginn der Bewegung mit gedrückter linker Maustaste auftritt

OnDragMove - Ereignis, das bei der Bewegung mit der linken Maustaste erzeugt wird

OnDragEnd - Ereignis, das nach dem Verschieben mit LKM erzeugt wird

OnPut - Objekt wird in ein anderes Objekt umgewandelt

OnGet - das Objekt wird in ein anderes Objekt umgewandelt

OnFocus - Objekt hat den Fokus erhalten

OnBlur - Objekt verliert den Fokus

OnResize - Objekt hat Größe geändert

OnParentResize - das übergeordnete Objekt hat seine Größe geändert

OnKeyPress - eine gedrückte Taste

OnChange - Wert eines Feldes geändert

usw.

Ausführlich, danke!

 
Lesen Sie den Thread, interessant. Es ist schade, dass es vor 3 Jahren nicht so einen Aufruhr um die Schnittstellen gegeben hat.

Ich sehe keinen Sinn darin, meinen Code zu veröffentlichen, da die Wahrscheinlichkeit groß ist, dass die Initiative aufgrund von Faulheit und Kommunikationsschwierigkeiten zwischen den Teilnehmern (und die sind bereits zu beobachten) untergeht, mein Code in den Keller geschleppt wird, um ihn für mich selbst zu modifizieren, und ich (und die Gemeinschaft) überhaupt keinen Nutzen daraus ziehen können.

Aber um an dem Projekt teilzunehmen, könnte ich, beginnend mit der Erörterung der notwendigen Funktionen und der Anpflanzung von spezifischen Implementierungsdetails, da es einen Nutzen in einem solchen, nennen wir es einen Rahmen gibt.

Der Vorteil ist einfach und wurde von Alex in den ersten Beiträgen angesprochen. Die Gemeinschaft kann die Entwickler des Terminals beeinflussen, um Änderungen an der MQL-Plattform vorzunehmen.

Ich wünsche mir folgende Verbesserungen (die sich direkt auf die Programmierschnittstellen beziehen):

  1. MQL-Anwendung - als ein separater Programmtyp, der andere nicht aufhebt (er hat kein onTick und keine Möglichkeit, sich auf das Standardsymbol zu beziehen - das ist ein Relikt der Vergangenheit, aber er hat die Möglichkeit, die Handelsumgebung eines beliebigen Symbols zu erhalten und zu handeln, weil alles mehrwährungsfähig ist), sollte die Anwendung nicht auf dem Chart eines bestimmten Symbols starten, sondern in einem eigenen Fenster. Wenn Sie ein solches Programm auf ein Diagramm ziehen, wird ein neues Fenster geöffnet. Und Drag and Drop ist nicht nötig - 2 Klicks im Navigator - öffnet auch ein neues Fenster. Dies ist vergleichbar mit der Forderung einiger Leute, eine API für das Terminal zur Entwicklung in einer anderen Sprache bereitzustellen. Entwickeln Thema - kann davon ausgegangen werden, dass ein solches Programm, speziell kompiliert, kann ohne ein Terminal ausgeführt werden (und aus Sicherheitsgründen, erlauben diese Kompilation nur durch den Markt). Es mag verrückt klingen, aber was wäre, wenn?
  2. Unterstützung für Vektorschriften von Drittanbietern, die als separate Datei dargestellt werden, und die Möglichkeit, sie als Ressource zu kompilieren (in der Dokumentation angegeben, aber nicht implementiert)
  3. Erfassung von Maus-Scroll-Ereignissen
  4. Rechtsklick-Menü sperren. Die rechte Taste wird jetzt bedient, ist aber nutzlos.
  5. Handhabung der System-Zwischenablage, um eigene Textbearbeitungselemente zu erstellen (einschließlich Mehrzeilen-Editor), Leertaste und Enter können bereits gesperrt werden - gut.
 

@Igor Volodin, @Combinator, @Anatoli Kazharski

Ich beginne mit dem wunden Punkt.)
Die Frage, die mich am meisten beschäftigt, ist eine Art Universalität/Abstraktion für die Speicherung von Rendering-Parametern.

----

Soweit wir wissen, verwenden alle Steuerelemente die gleiche Schriftart, Hintergrundfarbe und Textfarbe, usw.
Wenn alle diese Parameter für alle Steuerelemente gleich sind, dann hat die Schnittstelle ein gemeinsames Aussehen mit einem einzigen Konzept.

Aber wie speichert man sie? Denn die Kontrollen verwenden nicht immer alle Parameter.
+ Das System wird durch die Tatsache kompliziert, dass Elemente verschiedene Zustände haben, die Schrift- und Hintergrundfarben unterschiedlich verwenden sollten. Sie lauten Aktiv, Deaktivieren, Über, Auswählen, usw.
+ Es gibt Gruppen von Controllern - Reliefs (wie Button) und Eingabefelder (wie Edit, List), und wann ist der Hintergrund, um sie zu rendern

----

In der aktuellen Arbeitsidee habe ich ein minimales Attributelement der Klasse GAttribBase, das 5 grundlegende Parameter enthält (Schriftart/Größe, Hintergrund-/Rahmenfarbe, Rahmengröße)

Diese Basiselemente werden verwendet, um ein Array für die Zustände der Klasse GAttribut zu bilden (Aktiv/Disabvle/Over/Select, usw.).

Und dann wird GAttribut für die verschiedenen Elementtypen - Relief, bearbeitbar usw. - ausgefüllt.


Wir geben also die Rendering-Parameter einmal ein (wir speichern sie in xml), sie können bearbeitet werden, um verschiedene Designs zu erstellen, und wir verwenden sie global, ohne sie für jeden Controller zu definieren.

Wenn für einen Controller eigene Rendering-Parameter definiert werden müssen, erstellen Sie einfach ein eigenes GAttribut-Objekt in dem Steuerelement und geben Sie die gewünschten Farben an.

----

Dieses Modell funktioniert, das einheitliche Design ist im Handumdrehen erreicht, alle Bedienelemente nehmen die Farben aus dem gemeinsamen Feld.

Aber meiner Meinung nach ist das nicht universell. Der Benutzer versteht nicht, welche Parameter aus der GAttribBase-Basis für das Rendering dieses oder jenes Steuerelements verwendet werden.
Damit der Programmierer genau weiß, welche Farbe er ändern muss, müsste er sich die Rendering-Funktion des Steuerelements ansehen, was wirklich lästig ist.

-----

Wie auch immer, gibt es Ideen für den Programmierer, sich vom Farbmanagement zu befreien (vordefinierte Farben sofort zu verwenden und sich anfangs nicht mit ihnen zu beschäftigen).

Wenn er andererseits einige der Steuerelemente auf dem Bildschirm neu einfärben möchte, muss er nicht nachforschen, welche GAttribBase verwendet wird und in welchem Fall.

 
o_O:

@Igor Volodin, @Combinator, @Anatoli Kazharski

Generell - welche Ideen haben Sie, damit der Coder einerseits von der Farbarbeit befreit wird (so dass er die angelegten Farben gleich verwendet und sich nicht am Anfang mit ihnen herumschlägt)

Und wenn sie andererseits einige der Steuerelemente auf dem Bildschirm neu einfärben wollen, können sie dies tun, ohne sich in das Labyrinth der Zeichenfunktionen zu begeben und zu suchen, welche GAttribBase in welchem Fall verwendet wird.

Ok, Themen.

Zum Beispiel ist das Hauptobjekt unserer Anwendung, nennen wir es App, mit dem ConcreteTheme-Objekt verbunden.

Was ist ein Themenobjekt:
Farben (Hintergrund, Vordergrund, deaktivieren, aktiv usw.), Grundgrößen, Schriftgrößen für Standardfälle: titlesize, commonsize usw. Sprites für: Felder, Schaltflächen, Kontrollkästchen usw.

Ein neues Thema ist eine neue Klasse/Struktur mit geänderten Werten. Aber es ist besser, dass Themen vererbt werden können, indem nur bestimmte Parameter überschrieben werden.


Der Rest - die Hierarchie der Steuerelemente, in der jeder Controller einen der erforderlichen Werte des Objektthemas standardmäßig verwendet. Wenn es diese überschreiben muss, rufen wir eine Methode auf, die mit dieser Eigenschaft arbeitet und den neuen Wert angibt.

Zum Beispiel SetBgColor(XRGB(255,0,128));

CView - eine Basisklasse, die grundlegende ereignisbasierte Interaktion ermöglicht
- CRect - Koordinaten
- Cpanel hat eine bgcolor
- CButton hat ein Statusobjekt, jeder Status hat bg
- CText hat eine Textfarbe und Schrifteigenschaften
- CCircle

Und so weiter.

Wenn Sie xml zur Beschreibung der Elemente verwenden möchten,

dann müssen wir für jedes Steuerelement oder Primitiv eine generierende Klasse erstellen, nennen wir sie "build-container", die Attribute (bgcolor="(255,0,128)") den entsprechenden Methoden (SetBgColor(attrValue)) der Klasse zuordnet. Solche Build-Container werden von einem XML-Parser geparst, die Ausgabe ist ein Objekt, das mit den benötigten Werten initialisiert wird, oder mit Standardwerten, wenn keine Werte angegeben wurden.

 

Hier ist das Thema dasselbe wie bei mir - eine Reihe von GAttributoren für verschiedene Arten von Steuerelementen und deren Status.

aber Sie schlagen bereits den ersten Schritt auf dem Weg zur Transparenz für Programmierer vor - fügen Sie Funktionen zu bestimmten Steuerelementen hinzu, um deren Rendering-Eigenschaften zu ändern (SetBgColor usw.)

Grundsätzlich stimme ich zu, dass es klar sein wird, welche Farben es hat und was geändert werden kann.


eine solche Frage - impliziert das Thema eine Redundanz der nicht verwendeten Parameter?

Nehmen wir an, dass in meinem grundlegenden GAttribBase für einige Steuerelement (z. B. Schaltfläche) verwenden wir nur Hintergrundfarbe und Größe, und andere Parameter - Randdicke, etc. sind nicht in diesem Steuerelement verwendet.

Das heißt - haben Sie ein Basiselement für alle Kontrollen? wo ist die Information "für alle Fälle" gespeichert, oder haben alle Kontrollen nur ihre Parameter ohne den Universalitäts-Overhead?

 
o_O:

...

Im Allgemeinen - was sind einige Ideen für den Programmierer zu sein frei von der Handhabung von Farben (so dass es Standard-Farben verwenden würde und nicht mit ihnen am Anfang stören)

Und auf der anderen Seite - damit er, wenn er einen Controller auf dem Bildschirm neu einfärben will, nicht in die Wildnis der Rendering-Funktionen eintauchen und herausfinden muss, welche GAttribBase in welchem Fall verwendet wird.

Legen Sie für jedes Element Standardwerte fest. Wenn der Benutzer etwas ändern muss, sollte es für jede Elementeigenschaft eine Methode zum Festlegen eines neuen Wertes geben. So habe ich es jetzt gemacht.

Das habe ich noch nicht:

Wenn Sie die Eigenschaften aller Elemente in "zwei Zählungen" ändern müssen, erstellen Sie einfach separate Methoden (für gemeinsame Eigenschaften, die sich auf das Design beziehen und für alle Elemente gelten) in der Klasse, in der alle Schnittstellenelemente zugänglich sind.

Im Prinzip kann ich mir schon vorstellen, wie dies in meinem Schema umgesetzt werden könnte. Zum Beispiel durch Veranstaltungen. Aber dann in der Event-Handler jedes Element müssen wir dieses Ereignis zu behandeln (der Code ist aufgebläht). Zweite Möglichkeit: Erstellen Sie eine spezielle öffentliche Methode in einer Klasse, die allgemeine GUI-Ereignisse behandelt, oder noch höher, wo alle Zeiger auf GUI-Elemente gespeichert werden. Beide sind Basisklassen der benutzerdefinierten MQL-Anwendungsklasse, und der Benutzer hat direkten Zugriff auf sie. Es kann so etwas sein wie überladene ObjectSet-Methoden in MQL (z. B.ElementSet), bei denen (1) Eigenschaft und Wert oder (2) Eigenschaft, Modifikator und Wert angegeben werden müssen.

Aber all dies ist meine Argumentation für mein Schema. Ich schließe nicht aus, dass es sich noch sehr verändern wird, wenn ich mit dem Übergang beginne. Alles, was ich oben geschrieben habe, ist also möglicherweise nicht mehr relevant für das Thema, das hier diskutiert wird. )

1...67891011121314151617181920...45
Neuer Kommentar