Fragen von einem "Dummy" - Seite 12
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
BITTE BERATEN SIE MICH ÜBER DAS MOBILTELEFON.
WANN UND WANN WIRD IRGENDEINE UNTERSTÜTZUNG FÜR BENUTZERINDIKATOREN (NICHT STANDARD) ODER ADVISOREN AUF mql4 ODER mql5 REALISIERT?????????????????????????????
AUF WELCHEN PLATTFORMEN (Z. B. ANDROID) DIES UMGESETZT WIRD????????????????? UND WIE BALD?????????????
in Erwartung einer ANTWORT, danke für die Vorwarnung
Interesting:
Nun, ich bin mit dieser Schlussfolgerung nicht einverstanden. OCO == "das eine hebt das andere auf". Nun, im MT5 gibt es so etwas nicht, dass ein Auftrag den anderen storniert. Ich habe es ein Jahr lang bereut.Funktionen wie SL und TP schließen eine offene Position wirklich, aber die Frage der "Stornierung" schwebender Aufträge hat damit nichts zu tun.
Sie tun es, aber diese Aufträge werden auf dem Server ausgeführt. Und sie sind die einzigen, die bisher tatsächlich in das OCO-Schema integriert sind (und wir würden nicht im Traum daran denken, "If Done"-Aufträge direkt im Terminal und auf dem Server zu implementieren).
Bei der Eröffnung einer Position und dem Setzen von TP und SL im MT5 verwenden wir im Wesentlichen das gleiche Formular (das Ergebnis ist hier jedoch eine Position + 2 Stornoaufträge).
Nach Ihrer Nachricht habe ich mich bereits zu dieser Situation geäußert und dabei den SL und den TP als austauschbar bezeichnet. Hier möchte ich jedoch Folgendes hinzufügen.
Hätte man den Autoren der OCO-Befehle gesagt, dass ihre Erfindung im 21. Jahrhundert nur noch auf SL- und TP-Ebenen angewandt wird, wären sie sehr überrascht gewesen, dass der Anwendungsbereich ihres Geistesprodukts so stark eingeschränkt wurde :) .In der Tat ist alles verkehrt herum: Alle Materialien, die Sie lesen, beziehen sich auf dasselbe: CCA-Aufträge sind austauschbare Aufträge, deren Typen jetzt in der MQL5 ENUM_ORDER_TYPE-Aufzählung angegeben sind. Ich habe noch nie einen Hinweis auf den Zusammenhang zwischen CCA-Aufträgen und SL-TP-Niveaus gefunden. Der Ausführungsmechanismus kann also derselbe sein, aber es sind ENUM_ORDER_TYPE-Aufträge, die der Client ausführt, nicht aber SL-TP-Ebenen (gemäß MQ).
Wenn ich also von schwebenden Aufträgen schreibe, meine ich Aufträge aus der ENUM_ORDER_TYPE-Liste und nicht "abgeleitete" Aufträge, die auf SL-TP-Levels basieren.
______________
* Das "Derivat", weil jeder der OCO-Aufträge unterschiedliche SL-TP-Niveaus haben kann.
Meine Herren, die Wurzel des Verständnisses liegt in der Einfachheit der Plattform. Einfachheit für 99 % der Nutzer und bewusster Verzicht auf Komplikationen, die der verbleibende Prozentsatz der Nutzer verstehen kann.
Stellen Sie sich die Frage: "Was wäre nötig, um X Millionen Nutzer für die Finanzmärkte zu gewinnen? Mit genügend Erfahrung wird die Antwort nahe daran liegen, "ein einfaches System zu schaffen, das die Komplexität beseitigt und die Händler in einem einzigen Ökosystem vereint".
Anstatt die OCO-Ordereinstellungen zu häufen (das Panel ist wirklich nichts für den durchschnittlichen Verstand), haben wir ein sehr einfaches und geradliniges Ordermanagement-Schema mit integriertem SL/TP angeboten. Die überwiegende Mehrheit der OCO-Aufträge sind lediglich SL/TP für aktuelle Positionen. Durch die Integration von SL/TP haben wir die Anzahl der zusätzlichen Aufträge minimiert und die Verwaltung der Geschäfte erheblich vereinfacht.
ps: das Problem mit dem Bestellsystem ist gelöst
ps: das Problem mit dem Bestellsystem ist gelöst
ps: Das Problem mit dem Bestellsystem ist gelöst.
Es ist schade, dass es nicht möglich sein wird, normale (zuverlässige) SLs/TPs für einzelne Trades (nicht für Gesamtpositionen) zu machen.
Dadurch wird die Möglichkeit, mehrere Strategien für dasselbe Instrument/Konto (zuverlässig) zu handeln, sofort eingeschränkt.
Hali-vor sollte nicht wieder aufgenommen werden, ich erinnere mich an die Meinung der Entwickler (ein Instrument = eine Position = ein SL und ein TP)...
Zu welchem Typ (long oder ulong) gehört ORDER_MAGIC eigentlich ?
ENUM_ORDER_PROPERTY_INTEGER
ORDNUNG_MAGISCH
Kennung des Expert Advisors, der den Auftrag erteilt hat (vorgesehen für jeden Experten, der seine eigene eindeutige Nummer erteilt)
lang
Zu welchem Typ (long oder ulong) gehört ORDER_MAGIC eigentlich ?
ENUM_ORDER_PROPERTY_INTEGER
ORDNUNG_MAGISCH
Kennung des Expert Advisors, der den Auftrag erteilt hat (vorgesehen für jeden Experten, der seine eigene eindeutige Nummer erteilt)
lang
Ich denke, das Ergebnis sollte in den im Code deklarierten Typ konvertiert werden (es kann ein Druckfehler in der Dokumentation sein).
Wenn es sich um MqlTradeRequest handelt, ist es in diesem Fall höchstwahrscheinlich (ulong).
Meines Erachtens sollte das Ergebnis in den im Code deklarierten Typ konvertiert werden (vielleicht gibt es einen Druckfehler in der Dokumentation).
Wie für MqlTradeRequest, in diesem Fall ist es am wahrscheinlichsten (ulong), aber wahrscheinlich lang wird ohne Probleme tun.
Die Antwort liegt im Allgemeinen nicht in der Sache selbst. Die Frage war ganz klar: "Zu welchem Typ (long oder ulong) gehörtORDER_MAGIC eigentlich ?"
Lassen Sie uns versuchen, sachlich zu bleiben:
(1) Diese beiden Typen können ohne Transformationen deklariert werden.
2. Wenn Sie nur positive Werte von magik verwenden, ist es vorteilhafter, seinen Wert als ulong anzugeben (da es einen Bereich möglicher Werte von 0 bis 18 446 744 073 709 551 615 gibt).
3. Andererseits wendet die Klasse CExpert der Standardbibliothek long value bei der Initialisierung an (was die Angabe negativer Werte erlaubt, aber den Bereich der möglichen Werte verschiebt). Bei der Initialisierung dieser Klasse kann der Wert von magik also bereits zwischen -9 223 372 036 854 775 808 und 9 223 372 036 854 775 808 liegen.
Diese Aussage sollte überprüft werden.
4. Aber schon in der Klasse CTrade (aus der gleichen Standardbibliothek) hat der Zauberer einen Wert ulong, wie er aufgrund der Abfragestruktur sein sollte.
Lassen Sie uns einige vorläufige Schlussfolgerungen ziehen:
a) Die Arbeit mit magik in den Klassen CExpert und CTrade ist nicht konsistent, da im ersten Fall long angegeben wird, während im anderen Fall ulong;
b) Die fraglichen Klassen wurden von verschiedenen Personen entwickelt, oder der Satz und die Struktur der Parameter für bestimmte Funktionen in CExpert wurde mit Blick auf CTrade geschrieben (das vielleicht noch gar nicht existierte).
c) Die Arbeit der Sachverständigen, die an der Entwicklung und Dokumentation der Standardbibliothek beteiligt waren, ist nicht vollständig kohärent (obwohl sie meist eine recht gute Studie zu den wichtigsten Fragen gesehen haben).
d) Wenn ich es richtig verstehe, begrenzt das Zusammenspiel dieser beiden Klassen den Wert des Magiers auf einen Bereich von 0 bis 9 223 372 036 854 775 808. Diese Aussage sollte überprüft werden.
5. Die Struktur MqlTradeRequest hat den Typ ulong, um mit magik zu arbeiten. Alles ist völlig konsistent mit der Klasse CTrade, deshalb ist es logischer, den Bereich der möglichen Werte von Magier von 0 bis 18 446 744 073 709 551 615 anzugeben, wenn wir nur diese Klasse verwenden. Diese Aussage sollteüberprüft werden.
PS
Ich denke, die Entwickler haben die möglichen Werte eines Magiers absichtlich in den Bereich von 0 bis 9 223 372 036 854 775 808"geklemmt".
Die Entwickler scheinen die möglichen Werte einer Magie absichtlich in einen Bereich von 0 bis 9 223 372 036 854 775 808"gezwängt" zu haben.
Tatsächlich werden der Magie bis zu 8 Bytes an Informationen gegeben, die beliebig interpretiert werden können. Es kann datetime, double, 4 short, 8 char, oder 64 bits bit by bit sein.
Bei den Vieren reichten 4 Byte Magie aus, um alles zu kodieren, aber jetzt haben wir 8. Alles, was es braucht, ist der Wille.