Der Wolf

Versuchs mal im Chart mit Mausklick rechts - "Aktualisieren". Es kann auch am Indikator-Shift-Value liegen, d.h. dass der Indikator erst nach Ablauf des aktuellen Bar's, evtl. sogar erst nach Ablauf mehrer Bar's neu berechnet und aktualisiert wird.

Willkommen an Board und viel Erfolg bei der Brokersuche !

Da muss ich leider passen - ich kann mir nicht vorstellen, wie man das umsetzen könnte.

Ich schliesse mich meinen Vor-Postern an: herzlich willkommen an Board

Bitte gerne, und ich bin ich jetzt beruhigt, weil wie gesagt - bei einem nackten Chart überhaupt nichts geladen werden dürfte !

Gerne, hatte jetzt erst Zeit mir das Ganze nochmal näher zu betrachten und - mir ist da noch was eingefallen: 1. Die dll braucht man definitiv nicht, das file wird auch so geschrieben und gelesen ! 2. das Load-Script ist fehlerhaft, die for-Schleife muss durch eine while-Schleife ersetzt werden. Wundert mich, daß es bei Dir überhaupt geklappt hat ? Ich vermute weil im Chart in den Du Objekte hineinlädst schon Objekte vorhanden waren, sonst dürftest Du eigentlich überhaupt nicht in die for-Schleife reinkommen (bei einem nackten Chart liefert ObjectsTotal() nämlich 0 zurück. Hier die in Load dObjects~.mq4 gemachten Änderungen //for (int l_count_4 = 0; l_count_4 while (! FileIsEnding(l_file_0)) { //2012.01.20 TomNext-Der Wolf while anstatt for ... FileClose(l_file_0); //2012.01.20 TomNext-Der Wolf: Datei schliessen Damit sollten alle Objecte geladen werden. Es werden zwar noch einige Fehler protokolliert "object name passed to ObjectSet function cannot be an uninitialized or empty string", das könnte daher kommen, daß beim Save ja auch schon paar Fehler (4201) auftreten. Der Sache gehe ich aber nicht weiter nach, da die Objekte jetzt vollständig übernommen werden sollten. Anbei das geänderte Load Objects~.mq4 Load Objects~.mq4

Hallo Optionator, willkommen an Board ! Ich habe früher auch einige Strategien mit Eurex-Optionen entwickelt und gehandelt. Schade, daß es mittlerweile uninteressant geworden ist, sonst hätte ich mich gerne mit Dir über Optionen ausgetauscht.

Super, ist dann Deine Suche nach einem Script damit auch gelöst ?

Wenn bei Dir der SAVE geklappt hat, hast Du den LOAD schon probiert, bzw. gibt's da Fehler ? Btw. Das mit dem Export bzw. der DLL überschlaf ich nochmal, vielleich habe ich morgen noch einen Gedanken.

Nein, habe ich nicht benutzt, da im Programm Standardfunktionen, also keine Extra-Funktionen, die in einer Library stehen müssten, aufgerufen werden. Was ich herausgefunden habe: Der Fehler 4201 kommt erst ab der Property OBJPROP_DEVIATION, OBJPROP_FONTSIZE ... bis OBJPROP_LEVELWIDTH. Sollte ich jetzt wirklich die .dll einbauen - ich trau mich nicht - hab Angst vor trojanischen Pferden !

Kurzer Zwischenstand: Hab mal das Save Objects-Script auf einen Chart mit zwei Linien und einem Fibo-Zonen gejagt: Es kommt kein Output im File an, Grund ist der Error-Code 4201 ERR_UNKNOWN_OBJECT_PROPERTY. Muss mir mal die einzelnen Properties im Detail ansehen. Darüberhinaus fehlt im Script der FileClose-Befehl. Ich schau mal, ob ich da noch was machen kann.

Danke, war grade dabei dir dies mitzuteilen, daß da nur die exen zu sehen waren . Gerade waren doch noch in deinem letzten Post noch die Sourcen zu sehen, nach dem Editieren sind sie weg ? Beim Bearbeiten sind sie wieder zu sehen, hab's jetzt hoffentlich downloaded bekommen. Ich schau's mir mal an.

Das funktioniert nur innerhalb eines Charts durch Umschalten in die verschiedenen Timeframes. Vola sucht etwas, "ohne umschalten des Charts, in dem eh alle Objekte je nach Einstellung in allen TFs zu sehen sind", d.h. Chartübergreifend bzw. Fensterübergreifend. Dazu müsste man alle Objekte mit allen Parametern aus einem Chart-Window exportieren (z.B. in ein .csv-File) und danach in ein anderes Chart-Window importieren. Ich denke, es ist nicht unmöglich, sowas zu programmieren, zumindest für einfache Linien. Ich kenn halt nur kein solches fertiges Skript, sonst hätte ich's wohl längst in meiner Sammlung.

Ich kenn kein Script hierfür. Das hat nichts mit .DLLs zu tun.

Hier der Link zu Youtube, ist aus dem ursprünglichen Artikel verschwunden Und weil's auch zum 90. Rettungsgipfel paßt: Goldfingerle a la Euro Bond 2012 James Bond 007

Bin kein Free-Pascaler. Hätte evtl. einen anderen Lösungsansatz: erstmal eine .csv-Datei mit Hilfe der MQL-Filefunktionen erzeugen. Danach manuell die Pascal-DLL aufrufen, die die .csv-Datei einliest. Erst wenn das klappt dann evtl. Erweitern auf direkten Aufruf der DLL aus dem MQL-Skript.

Vielen Dank ! ist doch vollkommen okay so, ATR ist ja sowieso der kleinste gemeinsame Nenner, wer will kann das ja individuell ausdehnen (wie auch immer). Schönen Urlaub !

Das ist unter dem folgenden Link in Kapitel 11 und 12 beschrieben: http://www.metatrader-experts.de/wissen-ueber-metatrader-mql-programmierung-handelssysteme-und-trading/mt4tool/backtest-und-daten.html ... 11. Für reproduzierbare Backtests müssen Sie nun noch den Spread "einfrieren". Sie werden sich fragen: Warum? Ganz einfach, bei jedem Backtest den Sie durchführen wird MetaTrader genau den Spread verwenden, der im Moment des Starts des Backtests (als Sie den Button Start gedrückt haben) gerade im Markt vorhanden war. Wenn Sie nun beispielsweise einen ECN-Broker mit flexiblem Spread haben, wird Ihr Backtest (von ein und demselben Handelssystem) unter Umständen einmal mit 0.5Pkt Spread durchgeführt und 10min später mit 2,5Pkt Spread! Die sehr unterschiedlichen Resultate sind damit vorprogrammiert. Das gleiche gilt im übrigen für eine Optimierung, denn auch hier wird immer der gerade aktuelle Spread verwendet. 12. Sie müssen sich ausloggen, damit keine neuen Daten mehr geladen werden und dementsprechend auch kein Update des Spreads durchgeführt wird. Löschen Sie Ihr Passwort und loggen sich neu ein. Dadurch wird der Server Sie nicht mehr "akzeptieren" und die Connection wird getrennt. ...

Alles klar, hier die Fehlerbereinigung in der Funktion calcNewTrailingStop(). Fällt natürlich nur auf, wenn der externe Parameter TrailStopChandelier auf false und TrailStopParabolicSAR auf true stehen. //--- ParabolicSAR if (TrailStopParabolicSAR) { trailStopParabolic = iSAR(NULL,0,ParabolicSARStep,ParabolicSARMaximum,shiftParabilicSAR); if (trailStopParabolic > 0.0) { if ((orderType == OP_BUY && trailStopParabolic < Bid) || (OrderType()==OP_SELL && trailStopParabolic > Ask) ) { //o.k., ParabolicStop "passt" zur Order } else trailStopParabolic=curStop; } //Print("calcNewTrailingStop | trailStopParabolic="+trailStopParabolic+"| curStop="+curStop+"|OrderTicket="+OrderTicket()); } btw. ich habe bei Indikatoren für die Shift-Parameter Variablen verwendet und diesen i.d.R. 0-Werte zugewiesen. Wäre evtl. ein nächster Diskussionspunkt, ob man vielleicht generell eine (externe) Variable für (alle) Shift-Werte von Indikatoren verwendet. Möglicherweise könnte man auch die Variable EachTickMode dazu hernehmen, also wenn EachTickMode true dann Shift-Werte = 0 ansonsten Shift-Werte = 1. Wie seht ihr das ?

Super, danke ! Ist noch nicht ganz vollständig, habe noch einen Fehler im calcNewTrailingStop() beim Parabolic. Werde mir gleich die Version 1.0 holen, kurz mit meiner Korrektur antesten und stelle dann die geänderte Funktion in diesen Thread rein.

@Chandelier Ja, ich denke wir haben da ein kleines Missverständis. Bin gespannt, wie das die anderen sehen ? @Parabolic Ich habe den Parabolic bisher überhaupt nicht benutzt, nur rudimentär angetestet. Habe den Fehler bemerkt, daß ich noch den Ordertype und den alten Stop berücksichtigen muß. Bin bereits am Testen einer geänderten Version.

Er berechnet doch abhängig von der Richtung der letzten x Bars < HH der letzten x-Bars> - ATR*Faktor bzw. LL der letzten x-Bars> + ATR*Faktor Sobald das gebrochen wird, dann erfolgt der Wechsel auf die jeweils andere Seite. Es ist also nicht immer die gleiche Berechnung, sondern abhängig davon ob der aktuelle close sich über oder unter den letzten x Bars befindet. Der ChandelierExit kennt also nach meiner Ansicht nicht immer eine Berechnung sondern abhängig von der Richtung der letzten x Bars (also dem Trend) entweder einen oberen Wert oder einen unteren Wert. Und wenn nun die Chandelier-Richtung nicht mit der Trendfilter-Richtung übereinstimmt, dann gibt es keinen Wert für den Chandelier (=EMPTY_VALUE)

http://www.rp-online.de/digitales/internet/dinner-for-one-mit-merkozy-in-den-hauptrollen-1.2655879

Schau mal hier nach, da hat vor einiger Zeit Vola einen Link auf ein PDF reingestellt, in dem der ChandelierExit und der ParabolicSAR diskutiert werden. Thread #167 vom CommunityEA: http://www.tom-next.com/community/topic/59588-projekt-entwicklung-community-ea/page__view__findpost__p__124843 bzw. hier der Direkt-Link zu diesem PDF https://community.tradestation.com/discussions/data/20050225165005lebeau.pdf P.S.: ich benutze den Chandelier in erster Linie, kannst ja auch mit den Parametern herumspielen

Wingman ist im Zusamenhang mit dem initialStop per ChandelierExit aufgefallen, daß es Diskrepanzen zwischen den Einstiegs- bzw. Filtersignale und dem initialStop gibt. Leider wurde die Frage von Wingman in einen eigenen Thread "Anfängerfrage ChandeleierExit" ausgelagert. Ich sehe daher einen Abstimmbedarf für den initialStop. Hier die ursprünglichen Anforderungen an den CommunityEA: 1. Einstiege werden per HeikenAshi-Signal generiert, dies ist in der Funktion calcEntrySignal() realisiert 2. zusätzliche Filter zum Einstieg werden durch zwei MA's in der Funktion calcFilterSignal() realisiert 3. ein initialStop soll per ChandelierExit in der Funktion calcInitStopDiff() generiert werden Daraus ergeben sich voneinander unabhängige Ereignisse: wenn HA-Signal und Filter z.B. einen Down-Trend anzeigen und der ChandelierExit nicht, dann gibt es eben keinen InitalStop erforderlicher Diskussionsbedarf: Nehmen wir den ChandelierExit als zusätzlichen Filter auf ? Die Alternative wäre, einen anderern initial Stop zu verwenden, was aber m.E. nicht im Sinne der Anforderungen wäre, vor allem wenn dann im trailingStop sowieso der CE wieder ins Spiel kommt.