[ARCHIV] Alle Fragen von Anfängern, um das Forum nicht zu überladen. Fachleute, gehen Sie nicht vorbei. Nirgendwo ohne dich - 3. - Seite 248

Neuer Kommentar
 
Roman.:
ERR_INVALID_TRADE_VOLUME 131 Falsches Volumen - machen Sie sich mit diesem Formular vertraut und stellen Sie das Volumen entsprechend Ihres Kontotyps "richtig" ein, z.B. bei Mikrokonten ist das Volumen normalerweise 0,01 Lot, bei "klassischen" Konten = 0,1 Lot... Geben Sie einen konstanten Wert von 0,1 Lot in die Auftragseröffnungsfunktion ein und überprüfen Sie ihn...
EA handelt ein bestimmtes %-Lot von ekvit, d.h. ich kann nur Prozente wie 10, 5 eingeben, es gibt keine Möglichkeit, Lot 0.1 oder 0.01 einzugeben. Dieses Problem ist nur bei einem 4-stelligen Broker aufgetreten.
 
MeTrade:
MaxZ:
Haben Sie an Wochentagen getestet? Ist der Spread variabel?
Die ganze Woche über optimiert, heute Abend und heute Morgen getestet. Ist das ein Problem?
Sie haben meine Frage nach dem Spread nicht beantwortet.
 
Warum wird diese Meldung angezeigt? Es hat mich viel Mühe gekostet, herauszufinden, dass ich beim Vergleich einer Ziffer mit einem Bruchteil diese mit NormalizeDouble() normalisieren muss. Aber ich beschloss, es heute zum Spaß auszuprobieren, und die Meldung erscheint! Was sind diese Pannen? Oder keine Pannen?
      if (1.3320 == 1.3320)
         Alert("Ku!");
 
ScioMe:
Warum wird diese Meldung angezeigt? Es hat mich viel Mühe gekostet, herauszufinden, dass ich beim Vergleich einer Ziffer mit einem Bruchteil diese mit NormalizeDouble() normalisieren muss. Aber ich beschloss, es heute zum Spaß auszuprobieren, und die Meldung erscheint! Welche Art von Pannen? Oder nicht Glitches?
Welche Pannen gibt es? Diese Konstanten sind gleich. Die Bedingung ist erfüllt.
 
MeTrade:
Der EA handelt mit einem bestimmten % des ekvit, d.h. ich kann nur einen Prozentsatz eingeben, z.B. 10, 5, es gibt keine Möglichkeit, ein Lot von 0,1 oder 0,01 einzugeben. Dieses Problem ist nur bei einem 4-stelligen Broker aufgetreten.
dieses Problem tritt nur bei 4-stelligen Brokern auf: "...ich kann nur einen Prozentsatz eingeben, z.B. 10, 5" - also wird Ihre Berechnung ohne Volumennormalisierung vor der Ordereröffnung durchgeführt, d.h. am Ende ergeben Ihre 10 oder 5 Prozent 0,123 oder 1,548 Lots, was Fehler Nummer 131 verursacht, bitte korrigieren Sie die Funktion für die Lotberechnung oder fragen Sie einen Telepathen, da nicht genügend "Input" (Rohdaten) zu dem Thema vorliegen ...
 
ScioMe:
Warum wird diese Meldung angezeigt? Ich habe früher viel Mühe darauf verwendet, herauszufinden, dass ich beim Vergleich einer Zahl mit einem Bruchteil diese mit der Funktion NormalizeDouble() normalisieren muss. Aber ich beschloss, es heute zum Spaß auszuprobieren, und die Meldung erscheint! Welche Art von Pannen? Oder nicht Glitches?

1). Der Compiler kann diese Bedingung (if-Anweisung) einfach ignorieren.

2). Wenn der Compiler diese Bedingung jedoch nicht ignoriert, wird er jede Zahl in den Speicher schreiben und jeder Zahl 8 Bits zuweisen. Es vergleicht die Zahlen, nicht wie wir es mit den Augen tun, sondern Stück für Stück. Die Zahlen im Speicher sind identisch, und die Bedingung ist erfüllt.

Ich bin sehr überrascht von Ihrer Frage, denn ich kann nicht verstehen, wie diese beiden Zahlen (zwei Datensätze) nicht als gleich wahrgenommen werden können.

 
MaxZ:
Sie haben meine Frage nach dem Spread nicht beantwortet.
Ich habe es an einem 4-stelligen Terminal mit fester Spanne ausprobiert, alles ist in Ordnung. Aber es trat ein weiteres Problem auf, die Fehlernummer 131, die auf dem 5-stelligen Terminal nicht auftrat.
 
MeTrade:
Nach Ihrem Kommentar habe ich es auf einem 4-stelligen Terminal mit fester Spanne ausprobiert, alles ist in Ordnung. Aber es trat ein weiteres Problem auf, die Fehlernummer 131, die auf dem 5-stelligen Terminal nicht auftrat.
Ich muss hier sitzen und einfach versuchen zu raten! :))) Ich bin sicher, dass Sie auch die anderen Probleme lösen werden.
 

Meine MM-Berechnungsfunktion ist komplex, und in einem Teil davon, bei der Berechnung des Lots, gibt die Funktion 0,18 als maximal mögliches Lot zurück, und Sie können entweder 0,1, 0,2 oder 0,3 öffnen, d.h. der Schritt ist 0,1.

Wenn ich die Menge normalisiere, wird sie auf 0,2 abgerundet, und der Auftrag ist nicht mehr zulässig, obwohl die maximal zulässige Menge 0,18 beträgt. Was ist der richtige Weg, um sie abzurunden oder korrekt zu normalisieren?

 
MaxZ:

""""...
Я очень удивлён был Вашему вопросу, так как не могу понять как можно два эти числа (две записи) воспринять не равными??""""


Ich kämpfe schon eine Weile mit diesem Problem. Das hat mir fast das Gehirn zerbrochen! Das Problem war folgendes: Ich musste eine Gleichheitsbedingung in if () ausführen. Wir haben echte Zahlen verglichen. Ich konnte keine Benachrichtigung erhalten und habe mich gefragt, was zum Teufel da los ist. Diese Zahlen können Sie mit bloßem Auge sehen, dass sie gleich sind! Aber das Terminal druckt es nicht aus. Schließlich hatte ich den Verdacht, dass etwas nicht stimmte, aber ich konnte nicht herausfinden, was los war. Ich brauche die Hilfe der mql4-Gemeinschaft. Ich habe hier eine Frage gestellt, und danke, die Experten (es scheint Roman und andere gute Leute) haben geantwortet, dass beim Vergleich von realen Zahlen, muss ich sie mit NormalizeDouble() Funktion normalisieren. Das hat geholfen. Aber heute habe ich es ausprobiert und was ist los? Sie werden sicher ohne Normalisierung verglichen. Wie auch immer, ich bin zu dem Schluss gekommen, dass sie manchmal verglichen werden und manchmal nicht, also sollte ich sie besser normalisieren, um sicher zu gehen.
1...241242243244245246247248249250251252253254255...652
Neuer Kommentar