Fehler, Irrtümer, Fragen - Seite 249

Neuer Kommentar
 


alexluek:

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...)

Bitte senden Sie eine Anfrage an Desk mit dem Quellcode und wir werden es herausfinden.
 

Hat jemand mit der zweiten Version der ChartGetInteger-Funktion gearbeitet :

2. Возвращает true или false в зависимости от успешности выполнения функции.
В случае успеха значение свойства помещается в приемную переменную, 
передаваемую по ссылке последним параметром.

bool  ChartGetInteger(
   long    chart_id,        // идентификатор графика
   int     prop_id,         // идентификатор свойства
   int     sub_window,      // номер подокна
   long&   long_var         // сюда примем значение свойства
   );

? Es scheint, dass der Wert der Eigenschaft nicht an die empfangende Variable übergeben wird. Zumindest wird dieses Verhalten bei der Verwendung des Konstrukts

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))
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).
 
Yedelkin:

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, die Hintergrundfarbe anzufordern. Ich wollte an servicedesk schreiben, habe es aber vergessen.
 
Lizar:
Ja, so etwas gibt es. Ich habe nur versucht, nach der Hintergrundfarbe zu fragen. Ich wollte an servicedesk schreiben, aber ich habe es vergessen.
Okay, mache ich.
 
Yedelkin:

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

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))

Ich kann Ihren Code nicht sehen, aber er scheint korrekt zu sein:

long Chart=0,windows;
if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,0,windows))
  {
   //--- всё плохо
  }
 
uncleVic:

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:

Hmmm..., ja, ich hatte genau diesen Fehler - sah mir meinen alten Code an, in dem ich versuchte, diese Funktion zu verwenden.
 
uncleVic:

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:

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);

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.

 
Yedelkin:
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.

 
Yedelkin:

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.

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);
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!
1...242243244245246247248249250251252253254255256...3184
Neuer Kommentar
Grund der Beschwerde: