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
Es gab keinen Kommunikationsverlust, kein Überziehen von Zecken, und je größer die TF, desto seltener.
Und die Berechnungsmethode vom Startdatum bis zum Enddatum (ich habe herausgefunden, dass es 3 davon gibt) ohne
Wahrscheinlich passiert es (es werden alle Balken neu berechnet), aber es ist noch nicht genau und ich weiß nicht, wie ich es überprüfen kann.
aber das ist nur ein Gedanke - prüfen wir es...
Vielleicht gibt es einen anderen Ansatz, um dies zu vermeiden...
Yedelkin:
Natürlich gibt es einen Ansatz. Wenn(prev_calculated==0), wird die erste Berechnung für alle Balken durchgeführt. Anschließend führen wir für jeden neuen Tick (wenn 0 < prev_calculated < rates_total) Berechnungen wie for(int i=prev_calculated-1;i<rates_total;i++) nur für die zuletzt erschienenen Bars durch.Zeichnet immer noch nach. Auf diese Weise umgesetzt:
int calculated1=BarsCalculated(StdDev1Handle);
...................
if(CopyBuffer(StdDev1Handle,0,0,to_copy,ExtStdDev1Buffer)<to_copy)return(0);
......................
int data1=CopyOpen(Symbol1,0,0,rates_total,Open1Buffer);
.....................
for(int i=rates_total-2; i>=0; i--){
if(time[i]>=DateStart)
{
Es zeichnet dann nicht neu, aber vielleicht ist es über die Korrektheit des Codes der Arbeit
aber nicht im Terminal (aber wenigstens ist es jetzt nicht mehr so ausgeprägt...)
Zecken oder keine Zecken können immer noch neu gezeichnet werden.
Es entsteht der Eindruck, dass keine Kohärenz (Ursache-Wirkung-Beziehung) besteht.
Das Einzige, was mir dazu einfällt, ist ein schwacher Prozessor oder ein Hänger.
Das Einzige, was mir einfällt, ist ein schwacher Prozessor oder das Einfrieren des Terminals (MT5).
alexluek:
...................
Mal wird neu gezeichnet, dann wieder nicht, aber es geht nur um die Korrektheit des Codes.
und nicht im Terminal (aber wenigstens ist es jetzt nicht mehr so ausgeprägt...)
Hat jemand mit der zweiten Version der ChartGetInteger-Funktion gearbeitet :
? Es scheint, dass der Wert der Eigenschaft nicht an die empfangende Variable übergeben wird. Zumindest wird dieses Verhalten bei der Verwendung des Konstrukts
Die Funktion gibt true zurück, aber die Variable windows enthält den Wert, der bei der Initialisierung dieser Variable ermittelt wurde. In diesem Fall gibt die erste Version der Funktion einen korrekten Wert aus. (Und noch etwas Triviales: Wenn die abrufende Variable vom Typ long deklariert ist, erzeugt der Compiler eine Warnung).Hat jemand mit der zweiten Version der ChartGetInteger-Funktion gearbeitet :
? Es scheint, dass der Wert der Eigenschaft nicht an die empfangende Variable übergeben wird. Zumindest wird dieses Verhalten bei der Verwendung des Konstrukts
Die Funktion gibt true zurück, aber die Variable windows enthält den Wert, der bei der Initialisierung dieser Variable ermittelt wurde. In diesem Fall gibt die erste Version der Funktion einen korrekten Wert aus. (Und noch etwas Triviales: Wenn die abrufende Variable vom Typ long deklariert ist, erzeugt der Compiler eine Warnung).Ja, so etwas gibt es. Ich habe nur versucht, nach der Hintergrundfarbe zu fragen. Ich wollte an servicedesk schreiben, aber ich habe es vergessen.
Hat jemand mit der zweiten Version der ChartGetInteger-Funktion gearbeitet :
? Es scheint, dass der Wert der Eigenschaft nicht an die empfangende Variable übergeben wird. Zumindest wird dieses Verhalten beobachtet, wenn das Konstrukt
Die Funktion gibt true zurück, aber die empfangende Fenstervariable enthält den bei der Initialisierung dieser Variablen erhaltenen Wert. In diesem Fall gibt die erste Version der Funktion den richtigen Wert aus. (Und noch eine Kleinigkeit: Wenn die empfangende Variable mit dem Typ long deklariert ist, wird der Compiler eine Warnung ausgeben).Es klingt, als ob Sie eine falsche Funktion verwenden. Dies ist die erste Variante der Funktion (mit drei Parametern). Sie gibt nicht true zurück (wie Sie denken), sondern den Wert des Parameters
Ich kann Ihren Code nicht sehen, aber er scheint korrekt zu sein:
Sie scheinen die falsche Funktion zu verwenden. Dies ist die erste Version der Funktion (mit drei Parametern). Sie gibt nicht true zurück (wie Sie denken), sondern den Wert des Parameters
Ich kann Ihren Code nicht sehen, aber er scheint korrekt zu sein:
Sie scheinen die falsche Funktion zu verwenden. Dies ist die erste Version der Funktion (mit drei Parametern). Sie gibt nicht true zurück (wie Sie denken), sondern den Wert des Parameters
GUT. Schauen wir es uns an.
1. Die Funktion wird "dass" verwendet, weil Sie eine Funktion mit demselben Namen wie Ihr Beispiel zitieren. Es kann nur darum gehen, welche Version dieser Funktion (erste oder zweite) verwendet wird.
2. Tatsächlich hat die erste Variante der Funktion formal drei Parameter, während die zweite vier hat. In der Beschreibung des Parameters sub_window, der in beiden Varianten des Aufrufs vorhanden ist, heißt es jedoch eindeutig: "Für die meisten Eigenschaften ist die Nummer des Unterfensters nicht erforderlich". Es stellt sich die Frage, ob es notwendig ist, die Fensternummer für eine Eigenschaft wie CHART_WINDOWS_TOTAL (Gesamtzahl der Diagrammfenster einschließlich der Indikatorunterfenster) anzugeben ?
3 Es ist logisch anzunehmen, dass es nicht erforderlich ist, die Anzahl der Fenster/Unterfenster des Diagramms separat anzugeben, um die Gesamtzahl der Fenster/Unterfenster zu erhalten. Diese Schlussfolgerung wird durch das Beispiel direkt aus dem Handbuch selbst ( Abschnitt " Eigenschaften von Diagrammen") bestätigt:
Ein ähnlicher Ansatz wird im Abschnitt Chart Operations / ChartWindowOnDropped beschrieben.
Aus diesen Beispielen wird ersichtlich, dass die Autoren des Handbuchs der Meinung sind, dass es nicht notwendig ist, eine separate Anzahl von Unterfenstern anzugeben, um die Gesamtzahl der Fenster/Unterfenster in einem Diagramm zu ermitteln. Natürlich wird in den Beispielen die erste Variante der Funktion verwendet, aber da es sich um dieselbe Eigenschaft handelt (d. h. CHART_WINDOWS_TOTAL), wäre es logisch anzunehmen, dass die gleiche Schlussfolgerung auch für die zweite Variante der Funktion gilt. Vor allem, wenn man bedenkt, dass das Handbuch keine Vorbehalte gegen die Notwendigkeit enthält, für die zweite Variante der Funktion eine Teilfensternummer von Null anzugeben.
Ihr Beispiel legt nahe, dass der dritte Parameter(sub_window) immer für die zweite Variante der Funktion angegeben werden sollte, auch wenn die Eigenschaft selbst nicht die Angabe einer Subwindow-Nummer erfordert. D.h. im Gegensatz zur ersten Variante der Funktion (die sowohl mit zwei als auch mit drei Parametern verwendet werden kann), sind bei der zweiten Variante der Funktion immer alle vier Parameter erforderlich. Oder?
5. Wenn das stimmt, haben wir zwei Dinge festgestellt. Erstens erwies sich meine ursprüngliche Version des Problems als falsch. Zweitens ist der Grund für diese fehlerhafte Version, dass die Informationen im Handbuch unvollständig sind. Daher schlage ich eine Klarstellung im Handbuch vor: "Für die zweite Option gibt es keinen Standardwert, daher muss die Nummer des Teilfensters immer angegeben werden. Für die meisten Eigenschaften, die keine Nummer eines Unterfensters erfordern, ist die Angabe von 0 (Hauptdiagrammfenster)" erforderlich. Oder so ähnlich.
Danke für das Beispiel. Er ist kurz und bündig.
In der ersten Variante der Funktion hat intsub_window=0 einen Standardwert, so dass er weggelassen werden kann; in der zweiten Variante gibt es keinen solchen Standardwert, so dass er angegeben werden muss.
GUT. Lassen Sie uns das klären.
1. Die verwendete Funktion ist "dass", weil Sie eine Funktion mit demselben Namen wie Ihr Beispiel anführen. Es kann nur darum gehen, welche Version dieser Funktion (erste oder zweite) verwendet wird.
2. Tatsächlich hat die erste Variante der Funktion formal drei Parameter, während die zweite vier hat. In der Beschreibung des Parameters sub_window, der in beiden Varianten des Aufrufs vorhanden ist, heißt es jedoch eindeutig: "Für die meisten Eigenschaften ist die Nummer des Unterfensters nicht erforderlich". Es stellt sich die Frage, ob es notwendig ist, die Fensternummer für eine Eigenschaft wie CHART_WINDOWS_TOTAL (Gesamtzahl der Diagrammfenster einschließlich der Indikatorunterfenster) anzugeben ?
3 Es ist logisch anzunehmen, dass es nicht erforderlich ist, die Anzahl der Fenster/Unterfenster des Diagramms separat anzugeben, um die Gesamtzahl der Fenster/Unterfenster zu erhalten. Diese Schlussfolgerung wird durch das Beispiel direkt aus dem Referenzhandbuch selbst (Abschnitt Diagrammeigenschaften) unterstützt:
1. In Anbetracht der Tatsache, dass die Funktion tatsächlich überladen ist, können wir argumentieren, dass dies nicht der Fall ist (obwohl dies, wie Sie sich vorstellen können, umstritten ist);
2. Das ist der Punkt. Wenn ich die Logik der Funktionsüberladung in MQL5 richtig verstehe, kann die erste Option mit 2 oder 3 Parametern verwendet werden, während die zweite nur mit 4 Parametern verwendet werden kann.
Das heißt, wenn eine Funktion zwei oder drei Parameter erhält, verwendet MQL5 die erste Option, während es immer die zweite Option verwendet, wenn es 4 Parameter erhält.
Der Punkt ist, dass der Compiler bei seinen Aufrufen durcheinander kommt, wenn wir die zweite Variante mit einer Parameternummer ungleich 4 verwenden.
3. Es gibt eine kleine Ungenauigkeit in der Referenz (oder vielmehr eine leicht falsche Formulierung). Die meisten Eigenschaften erfordern keine Fensternummer, und in der ersten Option für solche Eigenschaften kann die Fensternummer weggelassen werden(in der zweiten Option muss sie angegeben werden, wird aber ignoriert).
Daraus folgt, dass der Compiler für dieses Beispiel die erste Variante der Funktion wählen wird.
Der Compiler wird diese Schlussfolgerung auf der Grundlage ziehen, dass der dritte Parameter in der ersten Variante weggelassen werden kann, während er in der zweiten Variante unbedingt vorhanden sein muss!