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
Beachten Sie, Peter, wie ich einen Mehrfarbverlauf mit 6 Farben implementiert habe.
wobei p von 0 auf 1 wechselt.
ZS Aber es gibt ein Problem mit der äußersten Farbe, das ich noch nicht beheben konnte.
Sehr originell. ) Ist p eine beliebige Benutzernummer, oder ist sie an einen Parameter gebunden?
Wozu ist das gut?
p=p*5;
Sie können die richtige Zahl auf einmal senden. p kehrt nach dieser Zeile nicht zum Ausgangswert zurück.
Hier:
können Sie schreiben:
und warum verwenden Sie nicht anstelle von
int n=MathRound(p);
?
Ist die ARGB-Funktion eine Standard CCanvas-Funktion oder Ihre?
Es gibt jedoch einen Fehler in der äußersten Farbe, der noch nicht behoben wurde.
Es wurde korrigiert:
Der obige Code wurde korrigiert.
Ist die ARGB-Funktion eine hauseigene Funktion von CCanvas, oder ist es Ihre?
ARGB ist eine Definition von CCanvas. Um das herauszufinden, klicken Sie mit dem Mauszeiger auf den Namen und drücken Sie Alt+G
Wozu ist das gut?
5 ist die Anzahl der Farben -1
und warum verwenden Sie es nicht anstelle von
ARGB ist eine Definition von CCanvas. Um das herauszufinden, fahren Sie mit dem Mauszeiger über den Namen und drücken Sie Alt+G
5 ist die Anzahl der Farben -1
Gut. Ich habe nicht kritisiert, sondern nur gefragt. Sie können gut mit Farben arbeiten.
Du kannst gut mit Farben umgehen.
Ich stimme zu. Aber es gibt eine Kategorie von Nutzern, die es anders brauchen.
Und was ist, wenn die zurückgegebenen Daten des Kanvas-Indikators 512 überschreiten? Die Puffer werden in diesem Fall nicht helfen. Und die Nutzer wollen einfach nur Daten von den Indikatoren in ihren Programmen erhalten. Und sie wollen nicht, um sie in den Körper des Expert Advisor (Ich werde eine Eule zu schonen - lassen Sie es fliegen, ohne Rasseln in der ...) einzubetten. Und sie wollen Daten zu jedem angeforderten Balken erhalten, nicht nur zu den sichtbaren Balken. Und das ist gerechtfertigt. Und das ist nicht nur durch Faulheit und den Wunsch, alles leicht und einfach zu bekommen, begründet, sondern auch durch die Anforderungen von TS.
Wenn es sich um die große Mehrheit der Nutzer handelt, die keine Programmierer sind, brauchen sie entweder die Eule oder den Indikator. Sie brauchen keinen Indikator für die Eule.
Ich habe nur einige Informationen zum Nachdenken gegeben, ich will nichts aufzwingen. Lassen Sie die Programmierer selbst entscheiden, was sinnvoll ist und was nicht. Ich persönlich denke jedoch nicht, dass ich die iCustom-Funktion in meinen EAs verwenden werde.
Vielleicht liege ich nicht ganz richtig.
Es ist logisch anzunehmen, dass ein Nutzer, der einen solchen Canvas-Bufferless-Indikator auf dem Markt gekauft oder heruntergeladen hat, dessen Daten in seinem EA verwenden möchte.
Am sinnvollsten erscheint mir dann der Austausch über eine eigens angelegte Struktur, die vom Hersteller dieses Indikators erstellt und über eine Ressource ausgelesen wird.
Der Programmierer sollte in seinem kanoval pufferlosen Indikator darauf achten, dass diese Struktur in der Ressource aktuell gehalten wird, und dem Benutzer die Inclu-Datei zur Verfügung stellen, in der diese Struktur bei den Ereignissen des Benutzers oder bei jedem Tick ausgelesen wird (es ist nicht sinnvoll, den Timer zu verwenden, denke ich).
Und der Benutzer müsste nur eine Zeile Code einfügen #include... und dann wird diese Struktur immer mit aktuellen Daten aus dem Indikator verfügbar sein.
Das wäre bequemer als die klassische Verwendung von iCustom, denn diese Struktur kann bequem benannte Variablen und Datenfelder verschiedener Typen enthalten (nicht nur vom Typ Double, wie in den Puffern des klassischen Indikators).
Ich bin mir ziemlich sicher, dass die Ressourcen von MQ auf die gleiche Weise implementiert sind wie die Puffer von indicator.
Ich glaube, ich bin nicht ganz richtig.
Es ist logisch anzunehmen, dass ein Nutzer, der einen solchen Cava-Indikator auf dem Markt gekauft oder heruntergeladen hat, dessen Daten in seinem EA verwenden möchte.
Am sinnvollsten erscheint mir in diesem Fall der Austausch über eine eigens angelegte Struktur, die vom Produzenten dieses Indikators erstellt und über eine Ressource ausgelesen wird.
Der Programmierer sollte in seinem canva bufferless indicator darauf achten, dass diese Struktur in der Ressource aktuell gehalten wird, und dem Benutzer die Inclu-Datei zur Verfügung stellen, die diese Struktur unter Verwendung der Benutzerereignisse liest.
Und der Benutzer müsste nur eine Zeile Code einfügen #include... und diese Struktur wird immer mit aktuellen Daten aus dem Indikator verfügbar sein.
Ich denke, es ist sogar bequemer als die klassische Verwendung von iCustom, weil es bequem benannte Variablen und Datenarrays enthalten kann und der Benutzer sich nicht darum kümmern muss, was die Puffernummer bedeutet, und nur eine Zeile Code in sein Programm einfügen muss, um vollen bequemen Zugriff auf die Indikatordaten zu haben.
Ich bin mir ziemlich sicher, dass die MQ-Ressourcen auf dieselbe Weise implementiert sind wie die Indikatorpuffer.
Der Mechanismus der Datenübermittlung über die Ressource selbst ist äußerst einfach. Es geht eher um die Art der "Kommunikation" zwischen den beiden Programmen. Ein Programm schreibt, das andere Programm liest. Daher muss das Programm, das Daten (Indikator) in die Ressource schreibt, das angegebene Nachrichtenformat einhalten, und das Programm, das liest, muss dieses Format "kennen". Dann wird die Kommunikation zwischen den Programmen universell und effizient sein.
Der Mechanismus für die Übertragung von Daten über die Ressource selbst ist äußerst einfach. Es geht vielmehr um die Art der "Kommunikation" zwischen den beiden Programmen. Ein Programm schreibt und das andere liest. Folglich muss das Programm, das seine Daten (Indikator) in die Ressource schreibt, das Nachrichtenformat einhalten, und das Programm, das liest, muss dieses Format "kennen". Dann wird die Kommunikation universell und anwendbar sein.
Natürlich wird es das. Schließlich wird der Empfangs- und Sendeteil von dem einzigen Entwickler übernommen, der den Indikator selbst entworfen hat.
Der Mechanismus der gemeinsamen Nutzung über eine Ressource ist nicht so einfach. Sie erfordert bestimmte Fähigkeiten. Das ist es, was ich als Vorteil dieser Methode sehe, denn es wird ein Privileg für fortgeschrittene Programmierer sein.
ZS Peter, vor einem Monat schien es Ihnen noch nicht so einfach und notwendig zu sein. Ich freue mich, dass Sie meine Botschaft gehört und verstanden haben. :))
Natürlich wird das so sein. Schließlich stammt der empfangende und sendende Teil von einem einzigen Entwickler, der diesen Indikator selbst entwickelt hat.
Der Mechanismus des Austauschs über die Ressource ist nicht so einfach. Sie erfordert bestimmte Fähigkeiten. Das ist es, was ich als Vorteil dieser Methode sehe, denn es wird ein Privileg für fortgeschrittene Programmierer sein.
ZS Peter, vor einem Monat schien es Ihnen noch nicht so einfach und notwendig zu sein. Ich freue mich, dass Sie meine Botschaft gehört und verstanden haben. :))
Ja, Nikolai, Ressourcen haben sich als eine sehr effektive Methode für den Datenaustausch zwischen Programmen erwiesen, und ihre Verwendung basiert auf den Gewerkschaften, von denen du mir erzählt hast (und auch Vasiliy). Vielen Dank also an Sie beide).
Der Mechanismus selbst, Daten in eine Ressource zu übertragen und aus ihr zu lesen, ist einfach genug, aber das Nachrichtenformat ist eine knifflige Angelegenheit, wenn man Universalität anstrebt. Wenn wir das Problem für einen bestimmten Indikator lösen, ist alles ganz einfach.