Fehler, Irrtümer, Fragen - Seite 362

 
Lizar:
Der Bedarf an solchen Funktionen wird mit der zunehmenden Anzahl von Objekttypen steigen. Und es wird notwendig, wenn Sie Objekte erstellen, bei denen Sie die Anzahl der Ankerpunkte nicht durch ihren Typ bestimmen können. Es kann zum Beispiel eine Polylinie sein. Aber für jetzt ist nicht sehr kritisch, aber es kann als ein Wunsch in Service Desk ausgeführt werden.

Im Moment ist es realistischer (wenn es einen solchen Bedarf gibt), einen Funktionsschalter zu erstellen, der die Anzahl der Ankerpunkte nach Objekttyp ausgibt.

Machen Sie einfach diese Tabelle (MQL5 Referenz / Standardkonstanten, Aufzählungen und Strukturen / Objektkonstanten / Objekttypen) in switch. Der Eingabeparameter der Funktion ist ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Es gibt keine versteckten Gefahren, da alle Typen starr an Ankerpunkte gebunden sind. Wenn jedoch Objekte mit einer variablen Anzahl von Punkten auftauchen, besteht ein dringender Bedarf an einer solchen Funktionalität.

 
Urain:

Der realistischste Weg (wenn Sie ihn brauchen) ist, eine Schalterfunktion zu erstellen, die die Anzahl der Ankerpunkte auf der Grundlage des Objekttyps angibt.


Ich habe schon vor langer Zeit nach einer Eigenschaft in ObjectGet gefragt.

Ich habe den Eindruck, dass dies mit der Logik in den Eingeweiden des MT5 zu tun hat.

Wahrscheinlich geht er einfach alle Punkte durch und prüft sie auf LEER. Und wenn ein Punkt eine normale Ziffer enthält, wird er aufgebaut.

Es besteht also kein direkter Zusammenhang zwischen Objekttyp und Anzahl der Ankerpunkte.

Deshalb haben Sie richtig bemerkt, dass Sie die Umstellung selbst vornehmen müssen.

 
Urain:

Der realistischste Weg (wenn Sie ihn brauchen) ist, eine Schalterfunktion zu erstellen, die die Anzahl der Ankerpunkte auf der Grundlage des Objekttyps angibt.

Machen Sie einfach diese Tabelle (MQL5 Referenz / Standardkonstanten, Aufzählungen und Strukturen / Objektkonstanten / Objekttypen) in switch. Der Eingabeparameter der Funktion ist ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Es gibt keine versteckten Gefahren, da alle Typen starr an Ankerpunkte gebunden sind. Aber wenn wir neue Objekte mit einer variablen Anzahl von Punkten bekommen, werden wir diese Funktion wirklich brauchen.

sergeev:

Ich habe schon vor langer Zeit nach einer Eigenschaft in ObjectGet gefragt.

Wenn es ein Objekt mit einer variablen Anzahl von Punkten gibt, dann ist eine solche Funktionalität äußerst wichtig.

Wahrscheinlich geht er einfach alle Punkte durch und prüft sie auf LEER. Und wenn ein Punkt eine normale Ziffer enthält, wird er aufgebaut.

Es besteht also kein direkter Zusammenhang zwischen Objekttyp und Anzahl der Ankerpunkte.

Bei einer variablen Anzahl von Punkten besteht ein extremer Bedarf an solchen Funktionen.

Ja, wie ich oben geschrieben habe, habe ich es per Schalter implementiert. Es funktioniert ohne Probleme. Aber die Idee geht noch weiter: Ich möchte mehr Komfort und Universalität.

Übrigens fände ich es gut, wenn die Benutzer ihre eigenen Objekte erstellen könnten. Zum Beispiel sollte es zumindest möglich sein, Standardobjekte in Gruppen mit einer gemeinsamen "Marke" zusammenzufassen. Damit wäre es möglich, eine Gruppe von Objekten als ein einziges zu bezeichnen. Dann gäbe es einige knifflige Objekte wie Polylinien, Ringe, Torus... und so weiter. Und sogar Objekte einiger Bedienfelder könnten zusammengeführt werden. Und Strg-B würde nicht ein Blatt mit Objekten, sondern saubere Namen von Objektgruppen oder etwas Ähnliches ergeben. Auch das Problem, 100000 Ereignisse von geänderten Objekten im OnChartEven()-Handler zu erhalten, wäre gelöst, da diese 100000 Objekte in einer Gruppe zusammengefasst werden könnten und nur ein CHARTEVENT_OBJECT_CHANGE-Ereignis erhalten. Alles in allem wäre es eine Schönheit. Natürlich können Sie all dies teilweise durch Klassen implementieren, aber nicht alles.

 

Lizar:

........ Und Strg-B würde nicht ein Blatt mit Objekten, sondern saubere Namen von Gruppen von Objekten oder so etwas anzeigen...........

....... da diese 100000 Objekte in einer Gruppe zusammengefasst werden könnten und nur ein CHARTEVENT_OBJECT_CHANGE-Ereignis erhalten. Alles in allem, eine Schönheit.......

Träumen Sie weiter, machen Sie sich keine großen Hoffnungen.

:)

 

Ich schreibe einen Indikator, der Candlesticks für mehrere Instrumente auf einmal anzeigt. Nach dem Start und bevor die neuen Balken erscheinen, wird alles korrekt angezeigt:

Aber nach dem Erscheinen der neuen Bars gibt es eine Verschiebung:

Und ChartRedraw ist nicht hilfreich. Wenn ich jedoch die richtige Taste - Aktualisieren - drücke, ist alles wieder an seinem Platz. Können Sie mir sagen, wie ich die Verschiebung verhindern kann?

Обработчик события "новый бар"
Обработчик события "новый бар"
  • 2010.10.04
  • Konstantin Gruzdev
  • www.mql5.com
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
Dateien:
 

Wird double price; in MqlTradeRequest automatisch normalisiert? (was unwahrscheinlich ist) und wenn nicht, warum gibt es immer noch keine Normalisierung in der Standardbibliothek? (Ich habe diese Frage vor 9 Monaten gestellt).

Ich habe mich aus der Situation befreit, indem ich einfach Änderungen in der Standardbibliothek vorgenommen habe, aber Sie wissen, dass das nicht der Fall ist (es wird beim Upgrade abgerissen).

bool CTrade::PositionOpen(const string symbol,ENUM_ORDER_TYPE order_type,double volume,
                          double price,double sl,double tp,const string comment)
{
...
m_request.price       =price; // ??????????
...
}

Wenn ich mich irre, was soll ich dann angeben?

Документация по MQL5: Стандартная библиотека
Документация по MQL5: Стандартная библиотека
  • www.mql5.com
Стандартная библиотека - Документация по MQL5
 

Wir führen die Normalisierung nicht automatisch durch, da wir den Preis des Händlers nicht ändern dürfen, um nicht der Willkür bezichtigt zu werden.

Sie müssen den Preis selbst normalisieren, wenn Sie den berechneten Preis verwenden. Wenn ein Auftrag mit unveränderten Netto-Geld-/Briefkursen erteilt wird, ist eine Normalisierung nicht erforderlich.

 
Renat:

Wir führen die Normalisierung nicht automatisch durch, da wir den Preis des Händlers nicht ändern dürfen, um nicht der Willkür bezichtigt zu werden.

Sie müssen den Preis selbst normalisieren, wenn Sie den berechneten Preis verwenden. Wenn ein Auftrag mit unveränderten Netto-Geld-/Briefkursen erteilt wird, ist eine Normalisierung nicht erforderlich.

Danke, ich habe herausgefunden, was ich wollte. Ich musste sogar Bid/Ask in 4 normalisieren.
 
Urain:
Danke, ich habe herausgefunden, was ich wollte. Sogar die Geld-/Briefkurse mussten in 4 normalisiert werden.

In MT4 brauchen Sie Bid und Ask nicht zu normalisieren. Sie sind standardmäßig immer normalisiert.

Wenn Sie ein Beispiel zur Hand haben, zeigen Sie es mir bitte.

 
Renat:

In MT4 brauchen Sie Bid und Ask nicht zu normalisieren. Sie sind standardmäßig immer normalisiert.

Wenn Sie ein Beispiel zur Hand haben, zeigen Sie es mir bitte.

Ich habe kein Beispiel zur Hand, es ist schon ziemlich lange her (vielleicht sind die aktuellen Builds in Ordnung), einmal gab es solche Probleme, dass ich Requotes in MT4 bekam, selbst wenn ich Bid und Ask anforderte, nach der Normalisierung ging alles gut, also gab es eine Regel, jede Anforderung zu normalisieren. Und Sie wissen ja, Gewohnheit ist die zweite Natur.
Grund der Beschwerde: