OrderClose() Rückgabewert
 

Hallo,

kurze Frage in die Runde. Wie geht ihr mit der Möglichkeit um, dass OrderClose auch mal einen false zurückliefern könnte also die Order nicht geschlossen wird? RefreshRates ist schon mal gut davor zu setzen meine ich und vielleicht eine Schleife mit 10 Wiederholungsversuchen oder gar noch was anders?

Hat jemand schon mal den Fall gehabt das OrderClose immer wieder false zurückgeliefert hat? Für das Ordermanagement wäre das schon eine böse Angelegenheit. Ich geh aber mal ganz optimistisch davon aus das dies eher sehr selten vorkommt. Habt ihr da eine Sicherheitskaskade wie Schleife etc?

C$D

Ja, man kann sich damit verrückt machen. Aber für den einen Fall wo wäre wenn, ist das Stoploss sonst da, oder ein TP.

Da hast Du die beiden wichtigsten Möglichkeiten schon genannt.
Es kommt auch auf den Fehler an. Der kann abfangen werden. Darauf wäre dann programmintelligent zu agieren.
In den Wiederholungsschleifen sollte eine Sleep()-Funktion eingebaut werden, mit einem Wert von mindestens 100 (also 100ms), sonst sind die 10 Schuss schnell verbraucht.
Auch auf das Ergebnis der permanenten Abfrage von IsTradeContextBusy()
sollte reagiert werden.

Und richtig, solange ein brokerreagierbarer SL an der Order klebt, sollte alles gut gehen (von Ausnahmen wie EURCHF mal abgesehen). Bei einem Hidden-SL wäre dann das Risiko schon wieder größer.

traderdoc

Danke euch das sind gute Punkte.

Wie hast du das angewendet? if(IsTradeContextBusy()==false) Als Filter vor Orderclose oder in die Schleife also nachdem OrderClose ein false geliefert hat?

Danke && Gruß

Die Frage ist, bezieht sich IsTradeContextBusy() nur auf den Zugriff des Orderpools oder auf alle Trade Functions wie auch OrderSend etc?

while(IsTradeContextBusy()){Sleep(100);} und gut ist :)

He, Gedankenübertragung! ich wollte gerade schreiben:

while(IsTradeContextBusy()) Sleep(100);

Die {} kannst Du an der Stelle weglassen.

traderdoc

Das nenne ich mal auf einen Nenner. So bekommt man doch langsam ein wohliges Gefühl beim Ordermanagement. Und wenn alle Stricke reissen gibt es den geliebten SL :)

oder auch nicht, denn wenn der quoteserver keine quoten ausspuckt, hilft der sl leider auch nicht, da der im tradecontextbusy oder sleep "festhängt".

kenne leider! keinen retail broker der garantierte sl gegen gebühr anbietet

mir fiel aber bei der chf action 2015 auf das das öffnen von positionen ohne probleme funktionierte, das schliessen jedoch zäh oder gar nicht...virtual dealer plugin?

Das ist die Erklärung dazu:
Returns true if a thread for trading is occupied by another Expert Advisor, otherwise returns false.

Außerdem würde der SL sehr wohl gezogen, egal ob der EA festhängt, weil der SL vom System aus ausgelöst werden würde und nicht über den EA. (SL wurde an die Order geknüpft! - Das hatte ich aber schon einmal vorausgesetzt).

traderdoc

das stimmt so nicht!
generiert der quoteserver keine quoten, gibt es keinen sl! da dieser gar nicht erreicht wird
der ea bekommt keine tickdaten! somit kann er einen hidden sl nicht exekutieren
ist die order mit sl abgesetzt, wird der sl im besten falle "bestens" exekutiert aber sicher nicht zum garantierten sl preis.

paradebeispiel war 2008, wo der markt gleichmal 1000pips flog..
sl würde maximal "bestens" exekutiert, mit mega minus! es kann muss nicht sein das er überhaupt exekutiert wird.

bekommt der orderbookserver von quoteserver keine quoten wird die order mit sl niemal exekutiert!
der oderbookserver hat keine kenntnis was sich abspielt!

quoteserver und orderbookserver müssen getrennt gehalten werden, sogar die mieseste regulierung schreibt das vor um manipulationen zu erschwerden!

Und ob das stimmmt! (Erst alles bitte richtig lesen!)
Was du schreibst ist doch alles soweit richtig, aber trifft nur zum geringen Teil auf das zu, was ich geschrieben hatte. Nämlich der SL hängt an der Order (also schon mal kein! HiddenSL). Und dann spielt es keine Rolle, ob der EA an dieser o.g. Stelle hängt oder nicht, weil sich das Auslösen des SL nicht mehr im Aufgaben- und Eingriffsbereich des EAs oder Users befindet.
Und bei meinem Satz: "Außerdem würde der SL sehr wohl gezogen..." ist mit keinem Wort die Rede, dass irgendwelche quoteServer und sonstigen Server nicht "funktionieren".
Das bitte ich hier strikt zu trennen, weil das zwei verschiedene Aspekte sind.

traderdoc

Ja, mit der Orderöffnung auch immer ein Brokerstopp zu setzen, davon war ich auch ausgegangen. Nur mit Hidden zu arbeiten ist natürlich gefährlich, es könnte auch einfach der Server/Computer kaputt gehen, Stromausfall und das neuste Argument für einen Brokerstopp aus der FF.de ist der Herzinfarkt. Man sollte selbst beim diskretionären Traden am besten auch den Stop zumindest mal den Notstop immer direkt mit dem Auftrag mitsenden.

Das in einem Extremfall keine Käufer auf der Gegenseite sind ist dann eine andere weitere Sache wo man sowieso mehr oder weniger Machtlos ist und sich aus dem Markt raushalten sollte sofern dies in gewissem Maße vorherzusehen sind.

C$D

ist. :rolleyes:

bezugnehmend auf posting #8 wo eine "wohlige" sicherheit durch sl angesprochen wurde.

es ist egal ob hidden oder mit ordersend oder ordermodify gesetzter sl, denn:

-wir sind näher an 2008, als manche glauben (öl!, china down, brics down usw)
-vorige woche gab es ohne news an manchen wp 350-380 tagespips
-manche news kommen nicht zu runden zeiten (11:00, 12:30) sondern 13:07 also nachträglich eingeschoben
-banken taumeln noch immer (db, unicredit, hypo)
-(teilweise)deflation
-großkonzerne bringen ihre geschäftszweige nicht an (panasonic, sony, toshiba, dt. telekom usa,....)
usw.

was bedeutet wenn das worst case szenario eintritt, es egal ist welcher sl, da es nur 3 echte möglichkeiten gibt, solch ein disaster halbwegs unbeschadet zu überstehen (egal ob manuell oder automatisch gehandelt)
-nicht traden, "0" risiko
-garantierter sl, kenne keinen retail broker mit garantiertem sl, wenn ja kostet es und in den agb's sicher hintertüren..
-jede position sofort asynchron hedgen

um ein beispiel anzufügen:
standard handel "old school":
buy mit 0.10, mit ordersend, ordermodify, hidden sl mit 100 pips
markt bricht wie 2008 mit 1800pips (gbpchf) weg
sl wird "bestens" erfüllt und mit -1000 pips geschlossen
verlust: 1000
normaler handel: wird der sl normal bei gesetzdem sl 100 ausgelöst sind es 100 verlust

asynchrone hedge lösung:
buy mit 0.10, sl 100pips
sell mit 0.05, tp 100pips
markt bricht wie 2008 mit 1800pips (gbpchf) weg
sl wird bestens erfüllt und mit -1000 pips geschlossen
verlust: 500! (-1000 (buy) +500 (sell))
normaler handel: wird der sl normal bei gesetzdem sl 100 ausgelöst sind es 50 verlust

swaps, spreads nicht gerechnet
ist man auf der richtigen, der positiven seite mit der buy 0.10 order dann ist es noch entspannter, zurücklehnen und abwarten,
dennn der pos. swap egalisiert spread, neg. swap usw.

was man aber bedenken sollte:
-sell fungiert wie versicherung
-man halbiert die verluste
-man halbiert aber auch die gewinne! entsprechende änderungen notwendig

daher ist es völlig "wurscht" welcher sl ob manuell oder automatisch, mit tradecontext, sleep, flags fürs orderclose, etc.
wenn kracht ist der karren bereits umgefallen - die tradingstrategie, in diesem fall der asynchrone hedge rettet einem die pips, bucks, dollars und NICHT der sl!

Bezugnehmend zu IsTradeContextBusy habe ich heute aus Interesse einen Test durchgeführt.

CPU Auslastung zu 100% und 8 EAs mit dem gleichen Symbol gleichzeitig je eine Order geöffnet und modifiziert.
Das Ergebniss bei zwei Demobrokern, es wurde kein einziges mal ein Fehler wegens des besetzten Context gebracht.
Die while(IsTradeContextBusy()) blieb bei false.

Evt. hat der MT4 schon Regulierungen enthalten und man kann diesen Bereich entspannter nehmen.