MetaTrader 5 / Beispiele
English
preview
Der MQL5 Standard Library Explorer (Teil 6): Optimierung eines generierten Expert Advisors

Der MQL5 Standard Library Explorer (Teil 6): Optimierung eines generierten Expert Advisors

MetaTrader 5 — Beispiele |
30 0
Clemence Benjamin
Clemence Benjamin


Inhalt


Einführung

Nach der Erstellung Ihres Expert Advisors – ob mit dem MQL5-Assistenten oder von Grund auf neu – empfinden Sie vielleicht ein starkes Gefühl der Zufriedenheit, da die Aufträge reibungslos und ohne Fehler ausgeführt werden. Wenn man sie jedoch durch den Strategietester laufen lässt, erhält man oft eine ernüchternde Realität: enttäuschende Ergebnisse, gekennzeichnet durch übermäßige Drawdowns, Overtrading oder uneinheitliche Rentabilität. Genau an dieser Stelle kommt die Optimierung ins Spiel, die es uns ermöglicht, Einstellungen, Logik und Einschränkungen zu verfeinern, um das wahre Potenzial des EA zu erschließen und eine robustere, nachhaltige Leistung zu erzielen.

Im Zusammenhang mit der MQL5-Entwicklung bezieht sich die Optimierung in der Regel auf den Prozess der Feinabstimmung der Parameter eines Expert Advisors mithilfe des Strategietesters von MetaTrader 5. Dies beinhaltet das systematische Testen verschiedener Eingabekombinationen – wie Signalschwellen, Zeiträumen oder Gewichtungen – anhand historischer Daten, um Konfigurationen zu ermitteln, die Schlüsselkennzahlen wie Nettogewinn, Gewinnfaktor oder Sharpe Ratio maximieren und gleichzeitig Risiken wie den maximalen Drawdown minimieren. Während diese Definition den Schwerpunkt auf die quantitative Parameterabstimmung legt, umfasst eine echte Optimierung ein breiteres Spektrum, das auch strukturelle und systematische Verbesserungen wie die zeitbasierte Filterung umfasst, die wir hier untersuchen werden. Diese Methoden befassen sich mit grundlegenden Problemen (z. B. Überreaktion auf Rauschen) vor oder neben der Parameteranpassung, um sicherzustellen, dass der EA nicht nur an vergangene Daten angepasst wird, sondern sich an reale Märkte anpassen lässt.

Dieser Teil baut direkt auf Teil 5 auf, in dem wir mit dem MQL5-Assistenten einen Multi-Signal-Expert Advisor konstruiert haben, und beschäftigt sich mit der Optimierung. Für Anfänger beweist dieser Teil-5-Meilenstein, dass voll funktionsfähige Handelssysteme mit minimalem Programmieraufwand zusammengestellt werden können, indem die MQL5-Standardbibliothek genutzt wird. Da wir jedoch vom Zusammenbau zur Praxistauglichkeit übergehen, werden wir verschiedene Optimierungsmethoden untersuchen – von der traditionellen Parameterabstimmung bis hin zu strukturellen Verbesserungen. Unser Hauptaugenmerk liegt dabei auf der systematischen, strukturellen Optimierung, insbesondere auf dem Einsatz von zeitbasierten Filtern, um exzessiven Handel und Überreaktionen auf Marktstörungen zu vermeiden.

Auch mit diesen Verfeinerungen auf Code-Ebene bleibt der Strategietester unverzichtbar: Er ermöglicht es uns, Änderungen rigoros zu testen, quantitative Verbesserungen zu beobachten (z. B. eine geringere Handelshäufigkeit oder glattere Equity-Kurven) und neue Ergebnisse mit Backtests aus der Zeit vor den Änderungen zu vergleichen. So können beispielsweise unterschiedliche Zeitfilter (z. B. die Beschränkung auf Überschneidungen von London/New York mit hoher Volatilität im Vergleich zu ruhigeren asiatischen Sitzungen) die Ergebnisse drastisch verändern, was deutlich macht, wie sich die Marktdynamik über verschiedene Zeiträume hinweg verschiebt, und die Notwendigkeit iterativer Tests unterstreicht, um Überoptimierungsfallen wie die Kurvenanpassung zu vermeiden.

Weitere wichtige Überlegungen bei der Optimierung sind das Risiko der Überanpassung (wenn der EA in historischen Tests überragend abschneidet, aber im Live-Betrieb aufgrund datenspezifischer Anpassungen versagt), die Bedeutung der Validierung außerhalb der Stichprobe (Testen auf nicht beobachteten Daten mittels Walk-Forward-Analyse) und die Empfindlichkeit gegenüber externen Faktoren wie Slippage, Spreads oder Nachrichtenereignissen. Durch die Kombination von struktureller Steuerung und von den Testern gesteuerten Anpassungen der Parameter schaffen wir widerstandsfähige Systeme, wobei wir den Fortschritt anhand von Vergleichsmetriken überprüfen, um echte Verbesserungen zu gewährleisten.

Wir werden nahtlos von der Diagnose zur praktischen Umsetzung übergehen und sicherstellen, dass Sie diese Techniken anwenden können, ohne die native Grundstruktur zu verwerfen.

Es ist wichtig, von vornherein festzuhalten, dass die von MetaQuotes angebotenen Signalmodule nicht schlecht konzipiert sind. Im Gegenteil, sie sind rechnerisch effizient, in sich konsistent und beruhen auf genau definierten Marktmodellen. Jedes Modul beinhaltet eine klare Interpretation des Preisverhaltens und bietet eine standardisierte Schnittstelle für die Teilnahme an einem kollektiven Entscheidungsprozess. Die Herausforderung, die sich uns stellt, ist also nicht die Qualität der Umsetzung, sondern der kontextbezogene Einsatz.

In dem Moment, in dem sich unser Ziel von der Zusammenstellung eines EA zur Verbesserung seiner Leistung in der Praxis verlagert, wird ein tiefgreifendes Verständnis erforderlich. In diesem Stadium ist die Arbeit über die Wizard-Schnittstelle hinaus nicht mehr optional. Der Assistent eignet sich zwar hervorragend für die Systemkonstruktion, aber eine sinnvolle Optimierung erfordert eine direkte Interaktion mit dem generierten Quellcode und ein Verständnis dafür, wie sich Signale unter verschiedenen Marktbedingungen verhalten.

In diesem Abschnitt wird der Schwerpunkt von der Montage auf die Verfeinerung verlagert. Anstatt sofort die Ausführungslogik oder das Geldmanagement zu ändern, konzentrieren wir uns auf die Signalbewertung und den Abstimmungsmechanismus selbst. Bei der Untersuchung der generierten Architektur zeigt sich eine entscheidende Erkenntnis: Die Hauptursache für die schlechte Leistung ist nicht die Signallogik, sondern das Fehlen von übergeordneten Einschränkungen wie Marktregime-Erkennung und Kontrolle der Handelsfrequenz.

Der Standard-Voting-Mechanismus aggregiert die Signalausgaben effizient und deterministisch. Jedes Signalmodul wertet seine internen Marktmodelle aus, ordnet seiner Prognose eine Stärke zu und trägt durch gewichtete Mittelung zu einer endgültigen Entscheidung bei. Dieses Verfahren ist technisch solide und rechnerisch effizient. Dieses Verfahren beruht jedoch auf der impliziten Annahme, dass Signale unabhängig vom Marktregime, der Volatilität oder der jüngsten Handelsaktivität kontinuierlich in die Entscheidungsbildung einfließen.

Diese Annahme wird in der Praxis problematisch. Die Märkte wechseln zwischen Trends, Seitwärtsphasen, Volatilität und geringer Aktivität, doch die meisten Signalmodule sind so konzipiert, dass sie nur unter bestimmten Bedingungen optimal funktionieren. Ohne Regimefilterung werden Signale, die in einer bestimmten Umgebung statistisch gültig sind, auch unter ungeeigneten Bedingungen ausgelöst. Gleichzeitig können durch das Fehlen von Häufigkeitsbeschränkungen wiederholte Bestätigungen ähnlicher Informationen zu vielen Positionseröffnungen führen, auch wenn keine bedeutenden neuen Marktinformationen vorliegen.

Die von unserem ersten Multi-Signal-Expert Advisor erstellte Equity-Kurve macht diese Einschränkung deutlich. Die beobachteten Verluste sind nicht auf fehlerhafte Indikatoren oder ineffizienten Code zurückzuführen. Stattdessen spiegeln sie ein System wider, das zu oft und ohne ausreichende kontextbezogene Zurückhaltung reagiert. Marktgeräusche werden immer wieder zu verwertbaren Informationen erhoben, was zu übermäßigem Handel, verstärkten Drawdowns und allmählicher Kapitalerosion führt.

Die Schlussfolgerung ist also nicht, die nativen Signalmodule zu ersetzen, sondern sie intelligent zu steuern und zu erweitern. Bei einer sinnvollen Optimierung geht es darum, zu kontrollieren, wann Signale in die Entscheidungsfindung einfließen dürfen, wie häufig sie Handelsaktionen auslösen dürfen und unter welchen Marktbedingungen ihre Interpretationen gültig bleiben.

Anstatt die nativen Quelldateien direkt zu modifizieren, lassen sich diese Verbesserungen am besten durch die Einführung nutzerdefinierter Signalschichten erreichen – entweder durch die externe Erweiterung des Verhaltens der vorhandenen Signallogik oder durch die Entwicklung neuer Signalmodule von Grund auf. Dieser Ansatz bewahrt die Integrität und Zuverlässigkeit der nativen Bibliothek und ermöglicht gleichzeitig eine präzise Steuerung des Signalverhaltens.

Zu diesen Optimierungsstrategien gehören:

  • Regimeklassifizierung (Trend, Bandbreite, Volatilitätszustand)
  • Handelsfrequenzdrosselung und Cooldown-Logik
  • Zeit-, sitzungs- und ereignisbasierte Filterung
  • Adaptive Gewichtung und bedingte Signalbeteiligung
  • Nutzerdefinierte Signalmodule, die die native Logik ergänzen, anstatt sie zu duplizieren

Wenn diese kontextbezogenen Schichten angewandt werden, schneiden die vorhandenen Signalmodule oft weit besser ab, als ihr Standardverhalten vermuten lässt.

In den folgenden Abschnitten werden wir den generierten Multi-Signal Expert Advisor im Detail untersuchen und systematische Optimierungstechniken vorstellen, die auf mehreren Ebenen arbeiten: interne Signallogik, EA-Eingänge, Regimefilter und Einschränkungen auf Entscheidungsebene. Indem wir die Verwendung von Signalen verfeinern, anstatt sie zu verwerfen, schaffen wir einen disziplinierten Weg zu robusten und nachhaltigen Leistungsverbesserungen. Von hier aus gehen wir zur praktischen Umsetzung über und beginnen mit der zeitbasierten Filterung, um zu zeigen, wie kleine, gezielte Code-Anpassungen das Overtrading drastisch reduzieren und gleichzeitig den Weg für weiteres Parameter-Tuning im Strategietester ebnen können.

Analyse des generierten Multi-Signal-Expert Advisors

Wie bei jedem komplexen Handelssystem beginnt eine effektive Optimierung mit der Zerlegung des Problems in seine beobachtbaren Komponenten. Unser Expert Advisor ist da keine Ausnahme. Die ungünstige Equity-Kurve, das unregelmäßige Backtest-Verhalten und die dichten Journalprotokolle sind keine zufälligen Anomalien – sie sind direkte, nachvollziehbare Folgen der Interaktion der internen Logik des EA mit den Marktdaten. Jeder eröffnete Handel, jeder anhaltende Drawdown und jede Episode von Overtrading sind auf bestimmte Entscheidungswege im Code zurückzuführen. Um sinnvolle Leistungssteigerungen zu erzielen, müssen wir zunächst feststellen, wo Entscheidungen getroffen werden, wie häufig sie vorkommen und unter welchen Bedingungen sie getroffen werden dürfen.

Anstatt zu versuchen, alle Aspekte gleichzeitig zu optimieren, konzentriert sich unsere Prüfstrategie bewusst auf den Kern der Entscheidungsfindung: die Signalauswertung und den Abstimmungsmechanismus. Das folgende Code-Snippet hebt die wichtigsten Signalmodule hervor, die in unserem von einem Assistenten erstellten Expert Advisor enthalten sind:

#include <Expert\Signal\SignalFibonacci.mqh>
#include <Expert\Signal\SignalAC.mqh>
#include <Expert\Signal\SignalMA.mqh>
#include <Expert\Signal\SignalRSI.mqh>

Diese vier Module – SignalFibonacci, SignalAC, SignalMA und SignalRSI – bilden den analytischen Motor des EA. Jeder interpretiert die Marktdaten durch seine eigene Brille, erstellt eine Richtungsprognose mit einer entsprechenden Stärke und trägt zu der kollektiven Entscheidungslogik bei, die darüber entscheidet, ob ein Handel ausgelöst wird. Komponenten wie Trailing Stops und Geldmanagement-Module (auf die wir in späteren Teilen eingehen werden) beeinflussen die Handelsergebnisse, nachdem die Einstiegsentscheidung bereits getroffen wurde. Wenn die Signale selbst übermäßig ausgelöst werden, in unpassenden Marktregimen ausgelöst werden oder dieselben Informationen redundant verstärken, kann keine nachgelagerte Ausführung oder Anpassung der Positionsgröße dies vollständig kompensieren. Daher muss eine echte Optimierung hier ansetzen: bei den Signalen, ihrer Kombinationslogik und den Governance-Regeln, die ihre Beteiligung steuern.

Diese gezielte Analyse erfüllt einen doppelten Zweck. Erstens zeigt sie auf, warum die Standardkonfiguration zu schlecht abschneidet – oft nicht, weil die Indikatoren fehlerhaft sind, sondern weil es ihnen an kontextbezogener Zurückhaltung fehlt. Zweitens werden die genauen Hebel ermittelt, die für Verbesserungen zur Verfügung stehen: Signalgewichte, Zulassungsschwellen, Abstimmungsschwellen, Frequenzkontrollen und bedingte Teilnahmeregeln. Indem wir diese Elemente systematisch untersuchen und die Auswirkungen gezielter Änderungen im Strategietester testen, können wir die Verbesserungen quantifizieren – indem wir die Handelshäufigkeit, die Glattheit der Equity-Kurve, die Drawdown-Statistik und den Gewinnfaktor vor und nach jeder Verfeinerung vergleichen. Unterschiedliche Parameter wie Handelszeitfenster oder Abkühlungsperioden zeigen, wie empfindlich die Ergebnisse auf den Marktkontext reagieren. Dies unterstreicht, dass strukturelle Steuerung und iterative Validierung der Tester untrennbare Bestandteile eines disziplinierten Optimierungsprozesses sind.

In den folgenden Unterabschnitten werden wir die kritischen Aspekte dieses Entscheidungskerns aufschlüsseln:

  1. Zusammensetzung der Signale und ihre vorgesehene Rolle auf dem Markt
  2. Gewichtskonfiguration und ihre Auswirkungen auf die Dominanz
  3. Schwellenwerte für die Zulassung von Signalen und die Ausführung von Geschäften
  4. Der Abstimmungs- und Erfassungsmechanismus – hier findet die eigentliche Aggregation statt
  5. Beobachtete Handelsfrequenz als diagnostischer Indikator für Überreaktion

1. Zusammensetzung der Signale und ihre vorgesehene Rolle auf dem Markt 

#include <Expert\Signal\SignalFibonacci.mqh>
#include <Expert\Signal\SignalAC.mqh>
#include <Expert\Signal\SignalMA.mqh>
#include <Expert\Signal\SignalRSI.mqh>

Obwohl diese Signalmodule als geschlossene, gebrauchsfertige Komponenten geliefert werden, sind sie nicht undurchsichtig. Jeder kapselt einen spezifischen Satz interner Marktmodelle, die aus dem Verhalten des Indikators abgeleitet sind, den er repräsentiert. Es ist wichtig zu verstehen, um welche Modelle es sich handelt, wie oft sie ausgelöst werden und wie stark sie das endgültige Abstimmungsergebnis beeinflussen. Ohne dieses Wissen wird das Kombinieren von Signalen eher zu einer Übung in blinder Aggregation als zu einem fundierten Systementwurf. Die erste entscheidende Frage ist, welche Rolle die einzelnen Signale in dem System spielen:

SignalFibonacci

Dieses Signal ist strukturell orientiert und kontextabhängig. Besonders relevant bei Rücksetzern, Korrekturen und Bereichen der Rückkehr zum Mittelwert innerhalb einer etablierten Struktur.

SignalMA

Trendorientiert. Am besten geeignet für die Identifizierung von Regimen oder direktionalen Verzerrungen und nicht für häufige Einstiegstrigger.

SignalAC (Accelerator Oscillator)

Momentumbasiert. Reagiert empfindlich auf kurzfristige Veränderungen und neigt zu häufigen Signalen.

SignalRSI

Oszillatorbasiert. Sehr empfindlich in Umgebungen mit einer großen Bandbreite oder einem niedrigen Zeitrahmen und eine häufige Quelle für Overtrading, wenn keine Beschränkungen bestehen.

Der Assistent weist diesen Signalen keine Rollen zu, sondern fasst sie lediglich zusammen.

2. Gewichtskonfiguration und ihre Auswirkungen auf die Dominanz

input double Signal_Fib_Weight = 1.0;
input double Signal_AC_Weight  = 1.0;
input double Signal_MA_Weight  = 1.0;
input double Signal_RSI_Weight = 1.0;

Die Gewichtung definiert den relativen Einfluss, nicht die Signalqualität. Wenn alle Gewichte auf 1,0 gesetzt werden, wird implizit angenommen:

  • alle Signale sind gleich informativ,
  • alle Signale sind für alle Marktregime gültig,
  • alle Signale sollten gleichmäßig und kontinuierlich beitragen, und
  • diese Annahme ist in der Praxis selten gültig.

Unsere Prüfstrategie umfasst systematische Experimente mit Gewichtsverteilungen und Beobachtungen:

  • Änderungen der Handelshäufigkeit
  • Verschiebungen in der Glattheit der Equity-Kurve
  • Verringerung oder Verstärkung von Absenkungen
  • Signaldominanz in den Journal-Logs

Gewichte werden zu einer der wichtigsten Abstimmungsvariablen während der Optimierung, insbesondere wenn sie mit Regime- oder Frequenzbeschränkungen kombiniert werden.

3. Schwellenwerte für die Zulassung von Signalen und die Ausführung von Geschäften

input int Signal_ThresholdOpen  = 10;
input int Signal_ThresholdClose = 10;

Die Schwellenwerte legen fest, wie stark das aggregierte Votum sein muss, bevor Maßnahmen ergriffen werden. Niedrige Schwellenwerte erhöhen die Empfindlichkeit, führen aber oft zu:

  • Übermäßige Häufigkeit des Handels
  • Reaktion auf Rauschen statt auf Information
  • Erhöhte Transaktionskosten und Inanspruchnahme von Leistungen

Wie in der Dokumentation hervorgehoben wird, handelt es sich bei den Schwellenwerten nicht um kosmetische Eingaben, sondern um strukturelle Kontrollen. Unsere Prüfung umfasst daher unterschiedliche Schwellenwerte und Beobachtungen:

  • Handelsdichte im Laufe der Zeit;
  • Signalclusterung in der Zeitschrift;
  • die Beziehung zwischen der Stärke der Stimme und dem Handelsergebnis.

4. Der Abstimmungs- und Erfassungsmechanismus – hier findet die eigentliche Aggregation statt

Dieser Block definiert die Signalsammlung, nicht nur die Signale selbst. Auf dieser Ebene beantwortet der EA kontinuierlich eine kritische Frage:

Welche analytischen Signaleinschätzungen dürfen aktuell an der Abstimmung teilnehmen?

Unsere Optimierungsarbeit beschränkt sich daher nicht auf die Änderung von Parametern. Sie beinhaltet auch:
  • die vorübergehende Deaktivierung einzelner Signale,
  • die Beobachtung von Veränderungen bei Equity und Häufigkeiten,
  • Bewertung der Redundanz zwischen Oszillatoren und
  • Prüfung asymmetrischer Kombinationen (z. B. nur Trend + Momentum).

5. Beobachtete Handelshäufigkeit als diagnostischer Indikator für Überreaktion

Innerhalb eines Zeitfensters von ca. 5,5 Stunden (00:30-06:05) generierte der EA weit über 60 Signalauswertungen und eröffnete 6 separate Marktpositionen, während er Stopps und Targets für dieselben Positionen dutzende Male änderte. Die Signale wurden fast alle 5 Minuten ausgelöst, wobei häufig zwischen langen und kurzen Interpretationen gewechselt wurde, ohne dass es zu einer sinnvollen Abkühlung oder Validierung des Systems kam. Diese Dichte an Signalaktivität deutet darauf hin, dass der EA die Schwankungen der Indikatoren als handlungsrelevante Ereignisse und nicht als kontextbezogene Informationen behandelt.

Zur Überprüfung haben wir einen kurzen Ausschnitt aus dem Journal des Strategietesters extrahiert, der ein fünfstündiges Zeitfenster der Marktaktivität abdeckt; einfachheitshalber habe ich im Folgenden nur einen Teil davon dargestellt.

2025.12.20 01:52:26.762 2024.11.07 00:05:00 Long Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 39.64, Diff: 3.12 | Weight: 70
2025.12.20 01:52:26.767 2024.11.07 00:10:00 Short Signal Detected: Pattern 2: Failed swing | Current RSI: 35.84 < Previous Extremum: 36.52 | Weight: 90
2025.12.20 01:52:26.769 2024.11.07 00:16:00 Short Signal Detected: Pattern 2: Failed swing | Current RSI: 34.29 < Previous Extremum: 36.52 | Weight: 90
2025.12.20 01:52:26.785 2024.11.07 00:20:00 Long Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 35.99, Diff: 1.70 | Weight: 70
2025.12.20 01:52:26.801 2024.11.07 00:25:00 Long Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 36.87, Diff: 0.88 | Weight: 70
2025.12.20 01:52:26.801 2024.11.07 00:25:00 position modified [#9152 sell 0.02 EURUSDr 1.07337 sl: 1.07326 tp: 1.06837]
2025.12.20 01:52:26.815 2024.11.07 00:25:00 CTrade::OrderSend: modify position #9152 EURUSDr (sl: 1.07326, tp: 1.06837) [done]
2025.12.20 01:52:26.912 2024.11.07 00:30:00 Long Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 37.80, Diff: 0.92 | Weight: 70
2025.12.20 01:52:26.912 2024.11.07 00:30:00 position modified [#9152 sell 0.02 EURUSDr 1.07337 sl: 1.07322 tp: 1.06837]
2025.12.20 01:52:26.926 2024.11.07 00:30:00 CTrade::OrderSend: modify position #9152 EURUSDr (sl: 1.07322, tp: 1.06837) [done]
2025.12.20 01:52:26.992 2024.11.07 00:35:00 Short Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 34.54, Diff: -3.26 | Weight: 70
2025.12.20 01:52:27.022 2024.11.07 00:40:00 Long Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 36.50, Diff: 1.96 | Weight: 70
2025.12.20 01:52:27.022 2024.11.07 00:40:00 position modified [#9152 sell 0.02 EURUSDr 1.07337 sl: 1.07316 tp: 1.06837]
2025.12.20 01:52:27.038 2024.11.07 00:40:00 CTrade::OrderSend: modify position #9152 EURUSDr (sl: 1.07316, tp: 1.06837) [done]
2025.12.20 01:52:27.070 2024.11.07 00:45:00 Long Signal Detected: Pattern 2: Failed swing | Current RSI: 38.01 > Previous Extremum: 37.80 | Weight: 90
2025.12.20 01:52:27.070 2024.11.07 00:45:00 position modified [#9152 sell 0.02 EURUSDr 1.07337 sl: 1.07310 tp: 1.06837]
2025.12.20 01:52:27.085 2024.11.07 00:45:00 CTrade::OrderSend: modify position #9152 EURUSDr (sl: 1.07310, tp: 1.06837) [done]
2025.12.20 01:52:27.133 2024.11.07 00:50:00 Long Signal Detected: Pattern 2: Failed swing | Current RSI: 38.53 > Previous Extremum: 37.80 | Weight: 90
2025.12.20 01:52:27.180 2024.11.07 00:55:00 Short Signal Detected: Pattern 0: Oscillator direction confirmation | RSI: 37.18, Diff: -1.35 | Weight: 70
2025.12.20 01:52:27.277 2024.11.07 01:00:00 Long Signal Detected: Pattern 3: Divergence | Bullish divergence detected | Weight: 80
2025.12.20 01:52:27.277 2024.11.07 01:00:00 position modified [#9152 sell 0.02 EURUSDr 1.07337 sl: 1.07288 tp: 1.06837]
2025.12.20 01:52:27.308 2024.11.07 01:00:00 CTrade::OrderSend: modify position #9152 EURUSDr (sl: 1.07288, tp: 1.06837) [done]
2025.12.20 01:52:27.324 2024.11.07 01:00:01 stop loss triggered #9152 sell 0.02 EURUSDr 1.07337 sl: 1.07288 tp: 1.06837 [#9153 buy 0.02 EURUSDr at 1.07288]

Noch kritischer ist, dass das Journal-Log zeigt, dass die Signalauswertung aggressiv fortgesetzt wird, selbst wenn die Positionen bereits geöffnet sind, was zu wiederholten Stop-Loss-Anpassungen und vorzeitigen Ausstiegen führt. Dieses Verhalten bestätigt, dass die Verluste nicht durch einzelne schlechte Trades verursacht werden, sondern durch eine übermäßige Entscheidungshäufigkeit und unkontrollierte Signalbeteiligung. Der EA reagiert in der Tat übermäßig auf Rauschen, was die Schlussfolgerung unterstreicht, dass bei der Optimierung die Begrenzung der Handelshäufigkeit, die Steuerung von Signalen und das Bewusstsein für das Regime im Vordergrund stehen müssen, nicht nur die Parametereinstellung.

Vom generierten Multi-Signal-EA erzeugte Equity-Kurve.

Die obige Equity-Kurve wurde von unserem Multi-Signal-Expert Advisor erstellt; sie zeigt einen stetigen und anhaltenden Rückgang und nicht etwa einzelne Verluste oder eine zufällige Volatilität. Dieses Verhalten deutet auf ein System hin, das ständig aktiv ist, aber strukturell nicht an die Marktbedingungen angepasst ist. Der Handel wird häufig eröffnet, die Verluste häufen sich allmählich an, und kurze Erholungsphasen ändern nichts am allgemeinen Abwärtstrend. Dieses Muster ist charakteristisch für eine exzessive Signalauslösung, bei der routinemäßiges Marktrauschen wiederholt als gültige Handelsmöglichkeiten interpretiert wird.

Die damit einhergehende Kapitalbelastung bestätigt diese Einschätzung zusätzlich. Das Marktengagement bleibt konstant hoch, mit häufigen Ausschlägen, die auf eng beieinander liegende oder sich überschneidende Trades hindeuten, selbst wenn sich die Equity-Kurve verschlechtert. Diese Beobachtungen belegen eindeutig, dass das Problem nicht in der Ausführung oder in einer Fehlfunktion der Indikatoren liegt, sondern darin, wie die Signale teilnehmen und kombiniert werden können. Die Ergebnisse unterstreichen die Notwendigkeit, über das Standardverhalten hinauszugehen und sich auf Optimierungsstrategien zu konzentrieren, die die Signalhäufigkeit, die kontextuelle Gültigkeit und die Entscheidungsdisziplin regulieren.

Jenseits der Equity-Kurve werden das Journal und das Handelsprotokoll zu wichtigen Kontrollinstrumenten. Durch die Analyse:

  • wie viele Abschlüsse pro Sitzung erfolgen;
  • ob sich mehrere Gewerke in flachen Bedingungen häufen;
  • wie oft Signale ohne neue Marktinformationen erneut ausgelöst werden.

Wir können daraus schließen, ob das Bewertungssystem auf Informationen oder lediglich auf Bewegungen reagiert. Diese Erkenntnisse fließen direkt in die späteren Umsetzungsschritte ein, wie z. B.:

  • Cooldown-Logik
  • Regimefilter
  • Bedingte Signalteilnahme
  • Kundenspezifische Signalveredelung oder Ersatz

Diese strukturierte Inspektion – die Untersuchung der Signalrollen, der Gewichtsverteilung, der Schwellenwerte und der beobachteten Handelshäufigkeit – bildet die Grundlage für die Umsetzung. Anstatt über Verbesserungen zu raten, identifizieren wir konkrete Hebel, die bereits in der EA-Architektur und -Dokumentation enthalten sind. Diese Beobachtungen führen uns zu gezielten Optimierungsstrategien, die darauf abzielen, einen Multi-Signal Expert Advisor auf kontrollierte, messbare und wiederholbare Weise zu verbessern.

Im nächsten Schritt gehen wir von der Inspektion zur Implementierung über, indem wir eine Logik zur Zeitfilterung entwickeln, mit der wir direkt steuern können, wann der Expert Advisor handeln darf. Die Parameterabstimmung ist ein unterstützender Schritt, der nur minimale Kodierung erfordert und sich in erster Linie auf die Anpassung von Werten durch Experimentieren konzentriert, um Konfigurationen zu ermitteln, die bessere Ergebnisse liefern – und das alles unter Beibehaltung der Integrität des nativen Frameworks.


Implementierung

Diese Phase ist von entscheidender Bedeutung, da wir unseren Schwerpunkt von der Analyse auf die Ausführung verlagern, indem wir die Logik der Zeitfilterung direkt implementieren. Durch die Einführung von kontrollierten Handelsfenstern können wir die unnötige Handelshäufigkeit deutlich reduzieren und genau bestimmen, wann der Expert Advisor arbeiten darf. Diese Verbesserungen werden durch minimale, gezielte Änderungen an unserem nutzerdefinierten Code implementiert, die es uns ermöglichen, das Verhalten des EAs zu steuern, ohne seine zentrale Signalarchitektur zu stören. Die meisten Optimierungserkenntnisse sind dem Abschnitt über die Ergebnisse vorbehalten, da sie größtenteils eine Feinabstimmung der Eingangsparameter und nicht eine umfangreiche Kodierung betreffen, was den Grundsatz unterstreicht, dass eine disziplinierte Steuerung die Komplexität oft übertreffen kann.

1. Implementierung der Kernzeitfilterung

Das Sitzungsmanagementsystem arbeitet direkt mit der Brokerzeit, sodass die Komplexität der Zeitzonen entfällt. Der Algorithmus konvertiert die aktuelle Serverzeit in ein minutenbasiertes Format, um einen genauen Vergleich mit den nutzerdefinierten Sitzungsgrenzen zu ermöglichen. Bei diesem Ansatz werden sowohl die normalen Tagessitzungen als auch die Nachtsitzungen durch eine bedingte Logik behandelt, die sich an die Mitternachtsüberquerungen anpasst. Das System bietet eine robuste zeitliche Firewall, die Handelsaktivitäten außerhalb der festgelegten Zeiten vollständig blockiert und gleichzeitig einen minimalen Berechnungsaufwand gewährleistet.

//--- Trading Session Parameters (using BROKER time)
input bool               EnableSessionFilter              =true;                  // Enable Session Filter
input string             Session_StartTime                ="09:00";               // Session Start (Broker time, HH:MM)
input string             Session_EndTime                  ="17:00";               // Session End (Broker time, HH:MM)
input bool               Close_Outside_Session            =false;                 // Close trades outside session?

bool IsTradingTime()
{
   if(!SessionEnabled) return true;
   
   datetime current_time = TimeCurrent();
   MqlDateTime time_struct;
   TimeToStruct(current_time, time_struct);
   
   // Get current hour and minute
   int current_hour = time_struct.hour;
   int current_minute = time_struct.min;
   int current_total_minutes = current_hour * 60 + current_minute;
   
   // Parse start time
   string start_parts[];
   int start_hour = 9, start_minute = 0;
   if(StringSplit(Session_StartTime, ':', start_parts) >= 2)
   {
      start_hour = (int)StringToInteger(start_parts[0]);
      start_minute = (int)StringToInteger(start_parts[1]);
   }
   
   // Parse end time
   string end_parts[];
   int end_hour = 17, end_minute = 0;
   if(StringSplit(Session_EndTime, ':', end_parts) >= 2)
   {
      end_hour = (int)StringToInteger(end_parts[0]);
      end_minute = (int)StringToInteger(end_parts[1]);
   }
   
   // Calculate session boundaries in minutes
   int session_start_minutes = start_hour * 60 + start_minute;
   int session_end_minutes = end_hour * 60 + end_minute;
   
   // Check if current time is within session
   if(session_end_minutes > session_start_minutes)
   {
      // Normal session within same day
      return (current_total_minutes >= session_start_minutes && 
              current_total_minutes < session_end_minutes);
   }
   else
   {
      // Session crosses midnight
      return (current_total_minutes >= session_start_minutes || 
              current_total_minutes < session_end_minutes);
   }
}

2. Verwaltungssystem für Handelslimits

Ein ausgeklügeltes quotenbasiertes System verhindert den Überhandel durch zwei Zählmethoden. Der historische Ansatz verfolgt alle Eröffnungstransaktionen innerhalb der aktuellen Sitzung unter Verwendung der Historienfunktionen von MQL5, während die alternative Methode nur offene Positionen überwacht. Dank dieser doppelten Funktion können Händler zwischen einer strikten historischen Nachverfolgung und flexiblen positionsbasierten Limits wählen. Das System setzt die Anzahl der Trades zu Beginn jeder neuen Sitzung automatisch zurück und nutzt dabei eine optimierte Überprüfungsfrequenz von 60 Sekunden, die Genauigkeit und Leistungseffizienz in Einklang bringt.

//--- Trade Limit Parameters
input bool               EnableTradeLimit                 =true;                  // Enable Maximum Trade Limit
input int                MaxTradesPerSession              =2;                     // Maximum trades per session (1-2)
input bool               CountAllPositions               =true;                   // Count all positions (true) or only open ones (false)

int CurrentTradeCount = 0;
datetime SessionStartTime = 0;
datetime LastResetCheck = 0;

bool CanOpenNewTrade()
{
   if(!SessionEnabled) return true;
   
   // Check if we're in trading session
   if(!IsTradingTime()) return false;
   
   // Check trade limit
   if(EnableTradeLimit)
   {
      // Update trade count
      CurrentTradeCount = CountSessionTrades();
      
      if(CurrentTradeCount >= MaxTradesPerSession)
      {
         Print("Trade limit reached: ", CurrentTradeCount, "/", MaxTradesPerSession, " trades this session");
         return false;
      }
   }
   
   return true;
}

3. Architektur der Integrationsschicht

Die geänderte Funktion OnTick() implementiert einen hierarchischen Entscheidungsfindungsprozess, der die Steuerlogik vor der Signalverarbeitung priorisiert. Diese Architektur schafft einen Unterbrechungsmechanismus, bei dem die Handelsgenehmigungen vor jeder Signalanalyse validiert werden. Die Integration behält die bestehenden Positionsmanagement-Funktionen für Trailing-Stops und Ausstiegssignale bei, während neue Handelseinträge vollständig blockiert werden, wenn die Bedingungen nicht erfüllt sind. Bei diesem mehrschichtigen Ansatz bleibt die ursprüngliche Logik der Signalerzeugung erhalten, während gleichzeitig disziplinierte Ausführungskontrollen hinzugefügt werden.

void OnTick()
{
   // Display current status on chart
   ShowStatusInfo();
   
   // Reset trade count if new session
   if(SessionEnabled)
   {
      ResetTradeCount();
   }
   
   // Check if we can open new trades
   bool can_open_trades = true;
   
   if(SessionEnabled)
   {
      can_open_trades = CanOpenNewTrade();
   }
   
   // Process trades based on conditions
   if(can_open_trades)
   {
      // Conditions met - allow normal trading
      ExtExpert.OnTick();
   }
   else
   {
      // Conditions not met - check if we need to close positions
      if(Close_Outside_Session && !IsTradingTime())
      {
         CheckSessionClose();
      }
      
      // Do NOT process any new trades when conditions are not met
      // This blocks ALL new trading activity
      return;
   }
}

4. Überwachung und Feedback in Echtzeit

Ein leistungsoptimiertes Anzeigesystem bietet sofortiges visuelles Feedback durch Diagrammkommentare, die einmal pro Sekunde aktualisiert werden. Diese Überwachungsebene zeigt den aktuellen Sitzungsstatus, den Fortschritt der Handelszählung und Systemwarnungen in Echtzeit an. Die Implementierung verwendet statische Variablen, um die CPU-Belastung zu minimieren und gleichzeitig wichtige Informationen sowohl für den Live-Handel als auch für Debugging-Zwecke zu liefern. Diese Transparenz hilft uns, genau zu verstehen, warum ein Trade zu einem bestimmten Zeitpunkt ausgeführt oder blockiert wird.

void ShowStatusInfo()
{
   static datetime last_print = 0;
   if(TimeCurrent() - last_print >= 1)  // Update every second
   {
      string current_time = TimeToString(TimeCurrent(), TIME_MINUTES);
      bool in_session = IsTradingTime();
      bool can_trade = CanOpenNewTrade();
      
      string status_text = "";
      
      if(SessionEnabled)
      {
         if(in_session)
         {
            if(EnableTradeLimit)
            {
               status_text = StringFormat("TRADING: %s-%s | Trades: %d/%d | Time: %s",
                                          Session_StartTime, Session_EndTime,
                                          CurrentTradeCount, MaxTradesPerSession,
                                          current_time);
            }
            else
            {
               status_text = StringFormat("TRADING: %s-%s | Time: %s",
                                          Session_StartTime, Session_EndTime,
                                          current_time);
            }
         }
         else
         {
            status_text = StringFormat("BLOCKED: Outside session %s-%s | Time: %s",
                                       Session_StartTime, Session_EndTime,
                                       current_time);
         }
         
         // Add trade limit warning if applicable
         if(in_session && EnableTradeLimit && CurrentTradeCount >= MaxTradesPerSession)
         {
            status_text += "\nTRADE LIMIT REACHED!";
         }
      }
      else
      {
         status_text = "TRADING 24/7: Session filter OFF | Time: " + current_time;
      }
      
      Comment(status_text);
      last_print = TimeCurrent();
   }
}

5. Technische Architektur Vorteile

Die Implementierung schafft ein modulares Filtersystem, bei dem jede Ebene unabhängig arbeitet und dennoch nahtlos integriert ist. Dieses Design ermöglicht eine zukünftige Erweiterung mit zusätzlichen Filtern wie Wochentagseinschränkungen oder volatilitätsbasierten Kontrollen. Die Architektur zeigt, wie algorithmische Disziplin zu bestehenden Handelssystemen hinzugefügt werden kann, ohne die Kernsignallogik zu verändern, und bietet eine Vorlage für systematische Handelsverbesserungen bei verschiedenen Expert Advisor-Designs.

CExpert ExtExpert;
CTrade Trade;
bool SessionEnabled = false;
int CurrentTradeCount = 0;
datetime SessionStartTime = 0;
datetime LastResetCheck = 0;

// ... Initialization in OnInit() ...
int OnInit()
{
   // ... existing initialization code ...
   
   // Initialize session parameters
   SessionEnabled = EnableSessionFilter;
   
   // Get initial trade count
   if(EnableTradeLimit)
   {
      CurrentTradeCount = CountSessionTrades();
      SessionStartTime = GetSessionStartDatetime();
      LastResetCheck = TimeCurrent();
   }
   
   // Display session info
   if(SessionEnabled)
   {
      Print("=== TRADING SESSION FILTER ENABLED ===");
      Print("Session Time: ", Session_StartTime, " to ", Session_EndTime, " (Broker Time)");
      Print("Close Outside Session: ", Close_Outside_Session ? "Yes" : "No");
      
      if(EnableTradeLimit)
      {
         Print("Maximum Trades Per Session: ", MaxTradesPerSession);
         Print("Count Method: ", CountAllPositions ? "All positions (including history)" : "Only open positions");
         Print("Current Trade Count: ", CurrentTradeCount);
      }
      
      Print("Current Broker Time: ", TimeToString(TimeCurrent(), TIME_DATE|TIME_MINUTES));
      Print("=====================================");
   }
   else
   {
      Print("Session Filter Disabled - Trading 24/7");
   }
   
   return(INIT_SUCCEEDED);
}


Tests

Die Implementierung zeitbasierter Filter hat unseren Expert Advisor grundlegend in ein diszipliniertes Handelssystem verwandelt, das die Handelshäufigkeit deutlich reduziert und gleichzeitig die Qualität verbessert. Durch die Beschränkung der Operationen auf bestimmte Sitzungen und die Durchsetzung eines maximalen Handelslimits haben wir eine präzise Kontrolle über den Ausführungszeitpunkt und das Risiko. Durch diese strategische Filterung werden ungünstige Marktbedingungen eliminiert, was zu weniger, dafür hochwertigeren Trades führt, die bessere risikobereinigte Erträge und einen kontrollierteren Verlauf der Equity-Kurve aufweisen.

Um eine weitere Optimierung und eine gleichmäßigere Leistungskurve zu erreichen, müssen wir nun systematisch die Kombinationen von Signalgewichten verfeinern, optimale Zeitfenster untersuchen und zusätzliche Filterschichten integrieren. Durch methodisches Testen von Parametern mithilfe von genetischen Algorithmen und Walk-Forward-Analysen können wir das System für eine konsistente Performance unter verschiedenen Marktbedingungen kalibrieren und schließlich einen robusten Handelsalgorithmus mit gleichmäßigem, aufwärts gerichteten Kapitalwachstum und kontrollierten Drawdown-Eigenschaften entwickeln.

Testen

Zeitlich gefilterter Handel:  Multi-Signal-Experte.

Equity-Kurve

Die Equity-Kurve, die sich unter zeitlich gefilterten Handelsbedingungen ergibt, unterscheidet sich deutlich von der früheren glatten, ununterbrochenen Abwärtskurve. Anstelle einer kontinuierlichen Verschlechterung zeigt das System nun ein zyklisches Equity-Verhalten mit abwechselnden Phasen der Erholung und des Rückgangs. Dies bestätigt, dass es sich bei den früheren Verlusten nicht um reine Signalausfälle handelte, sondern um eine Folge der uneingeschränkten Ausführung zu ungeeigneten Marktzeiten, bei denen Rauschen, geringe Liquidität oder Nichtübereinstimmung mit dem Marktregime die Ergebnisse dominierten.

Durch die Einführung zeitbasierter Kontrollen reagiert der EA nicht mehr wahllos auf jedes gültige Signal. Die Handelsaktivität wird auf bestimmte Sitzungen konzentriert, wodurch das Risiko in statistisch ineffizienten Zeiträumen verringert wird. Das Ergebnis ist eine geringere Handelsdichte, eine bessere Handelsverteilung und eine moderatere Drawdown-Struktur, obwohl die zugrunde liegende Signallogik unverändert bleibt. Dies bestätigt unmittelbar unsere Ausgangshypothese, dass die Festlegung des Zeitpunkts, zu dem die Signale wirken dürfen, ebenso wichtig ist wie die Signale selbst.

Aus Sicht der Inspektion unterstreicht dieses Ergebnis die Notwendigkeit, die erzeugte EA als Beweis für ein strukturelles Problem zu behandeln – nämlich eine übermäßige Teilnahmefrequenz und nicht eine fehlerhafte Signalinterpretation. Das Verhalten des Systems spiegelt nun eine bewusste Ausführung anstelle einer mechanischen Überreaktion wider, was einen entscheidenden Schritt in Richtung einer disziplinierten algorithmischen Steuerung darstellt.

In Zukunft ermöglicht dieser Rahmen eine weitere Verfeinerung durch kontrollierte Optimierung von Sitzungsfenstern, maximalen Trades pro Intervall und regelbasierten Teilnahmeregeln. Entscheidend ist, dass diese Verbesserungen die Integrität der nativen Signalarchitektur bewahren und gleichzeitig unser Ziel vorantreiben: ein vorhersehbares, risikoangepasstes Handelssystem, das durch Ausführungsdisziplin und nicht durch die Fülle der Signale bestimmt wird.


Schlussfolgerung

In diesem Teil haben wir einen von einem Assistenten generierten Multi-Signal-Expert Advisor erfolgreich verbessert – nicht durch die Überarbeitung des gesamten Systems, sondern durch das Hinzufügen einer durchdachten Steuerung: zeitbasierte Handelsfilter. Diese einfache, aber wirkungsvolle Änderung gab uns die direkte Autorität darüber, wann der EA Trades eröffnen darf, und verwandelte ihn von einer reaktiven, lärmenden Maschine in eine diszipliniertere und zurückhaltendere Strategie. Wir sahen deutliche Verbesserungen: weniger unnötige Trades, eine verbesserte Equity-Kurve und Drawdowns, die sich viel kontrollierter anfühlten als zuvor. Diese Ergebnisse beweisen, dass selbst bescheidene strukturelle Änderungen echte Fortschritte bringen können, ohne die Codebasis zu verkomplizieren.

Auf dem Weg dorthin haben sich mehrere wichtige Lektionen herauskristallisiert. Erstens sind die schädlichsten Performanceprobleme oft darauf zurückzuführen, dass zu häufig und unter den falschen Marktbedingungen gehandelt wird, und nicht auf fehlerhafte Indikatoren oder eine schwache Logik. Zweitens kann die Einführung einer einzigen, gut gewählten Einschränkung – z. B. die Begrenzung der Aktivität auf bestimmte Handelssitzungen – das Überhandeln drastisch reduzieren und das Gesamtverhalten verbessern. Drittens spielt die Wahl des Zeitrahmens eine große Rolle: Niedrigere Zeitrahmen erzeugen in der Regel mehr Rauschen und mehr Trades (was sich in der Regel negativ auf die Ergebnisse auswirkt), während höhere Zeitrahmen weniger, aber oft zuverlässigere Signale erzeugen. Schließlich schaffen diese Art von Strukturverbesserungen ein viel stärkeres Fundament. Sobald der EA nicht mehr überreagiert, wird jede nachfolgende Parametereinstellung im Strategietester viel sinnvoller und weniger anfällig für irreführende „optimierte“ Ergebnisse.

Was wir hier behandelt haben, ist nur ein Teil des Optimierungspuzzles. Es gibt noch viele weitere leistungsstarke Techniken, auf die wir noch nicht eingegangen sind: Regime-Klassifizierung, adaptive Signalgewichtung, Cooldown-Perioden nach dem Handel, volatilitätsbasierte Filter, ereignisgesteuerte Ausschlüsse, Walk-Forward-Analyse, Monte-Carlo-Simulationen und vieles mehr. Jede dieser Methoden kann den EA auf die nächste Stufe heben, aber sie erhöht auch die Komplexität. Deshalb heben wir sie für zukünftige Teile der Serie auf. Während wir schrittweise auf fortgeschrittenere Themen hinarbeiten, werden wir diese Konzepte nach und nach einführen, wobei wir sie immer auf der Grundlage der jetzt geschaffenen Grundlagen testen.

Ich habe den vollständigen aktualisierten Quellcode unten angehängt, damit Sie mit verschiedenen Handelsfenstern experimentieren, sie mit Ihren eigenen Ideen kombinieren oder genau sehen können, wie die Filter implementiert wurden. Die Optimierung ist eine fortlaufende Reise, und es gibt noch viel mehr, was wir gemeinsam entdecken können.

Danke, dass Sie uns gefolgt sind. Ihre Kommentare, Fragen, Testergebnisse und Vorschläge sind immer willkommen – sie helfen uns, die weitere Entwicklung der Serie zu steuern. Bis zum nächsten Teil – viel Spaß beim Codieren und sicheren Handel.

Quelldatei Version Beschreibung:
SignalFibonacci.mqh 1.0 Unverändertes Standardsignalmodul, das aus Teil 5 wiederverwendet wird. Diese Datei muss enthalten sein, um Kompilierungsfehler zu vermeiden, da sie die vom EA benötigte Fibonacci-Signallogik enthält.
Multi-Signal_Expert.mq5 1.1 Aktualisierter, von einem Assistenten generierter Expert Advisor mit verbesserten Ausführungskontrollen, optimierten Signalschwellen und sitzungsbasierten Handelsbeschränkungen. Diese Version konzentriert sich auf die Verringerung der Handelshäufigkeit und die Verbesserung der Handelsqualität, ohne dass die Kernsignallogik verändert wird.

Übersetzt aus dem Englischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/en/articles/20478

Beigefügte Dateien |
ZIP herunterladen
Multi-Signal_Expert.mq5 (21.33 KB)
SignalFibonacci.mqh (17.77 KB)

Warnung: Alle Rechte sind von MetaQuotes Ltd. vorbehalten. Kopieren oder Vervielfältigen untersagt.

Dieser Artikel wurde von einem Nutzer der Website verfasst und gibt dessen persönliche Meinung wieder. MetaQuotes Ltd übernimmt keine Verantwortung für die Richtigkeit der dargestellten Informationen oder für Folgen, die sich aus der Anwendung der beschriebenen Lösungen, Strategien oder Empfehlungen ergeben.

Clemence Benjamin
Clemence Benjamin
  • https://www.mql5.com/en/users/billionaire2024/seller
    • Hochmotivierter Entwickler von Forex-Trading-Tools. Ich bin Content-Ersteller und inspirierender Dozent und sorge für ein angenehmes Trading-Umfeld.
    Benötigen Sie Unterstützung bei der Entwicklung Ihrer Idee von Grund auf? Ich helfe Ihnen gerne, sie zu einem erschwinglichen Preis umzusetzen. Bieten Sie mir gerne einen Job über diesen Link an:
    https://www.mql5.com/en/job/new?prefered=billionaire2024
    Werden Sie Teil unseres Top-Brokers:
    https://track.deriv.com/_r6xDODPy3Ly2vdm9PpHVCmNd7ZgqdRLk/1/
    YouTube-Kanäle unserer Produktberater:

    Andere Artikel von diesem Autor

    Zur Diskussion im Händlerforum
    MQL5-Handelswerkzeuge (Teil 14): Pixelgenaues, scrollbares Textpanel mit Anti-Aliasing und abgerundeter Scrollleiste MQL5-Handelswerkzeuge (Teil 14): Pixelgenaues, scrollbares Textpanel mit Anti-Aliasing und abgerundeter Scrollleiste
    In diesem Artikel verbessern wir das Canvas-basierte Kurs-Dashboard in MQL5, indem wir ein pixelgenaues, scrollbares Textpanel für Bedienhinweise hinzufügen und die Einschränkungen des nativen Scrollens mithilfe von benutzerdefiniertem Anti-Aliasing sowie einer abgerundeten, sich bei Hover verbreiternden Scrollleiste umgehen. Das Textpanel unterstützt themenabhängige Hintergründe mit einstellbarer Transparenz, dynamischen Zeilenumbruch für Inhalte wie Anleitungen und Kontaktinformationen sowie eine interaktive Navigation über Schaltflächen zum Hoch- und Herunterscrollen, Ziehen von Schiebereglern und Scrollen mit dem Mausrad innerhalb des Textpanels.
    Workshop für nutzerdefinierte Indikatoren (Teil 1): Aufbau des Supertrend-Indikators in MQL5 Workshop für nutzerdefinierte Indikatoren (Teil 1): Aufbau des Supertrend-Indikators in MQL5
    So erstellen Sie in MQL5 für MetaTrader 5 einen Supertrend ohne Repainting von Grund auf. Wir verwenden ein iATR-Handle und CopyBuffer für die Volatilität, binden Puffer mit SetIndexBuffer und konfigurieren Plots (DRAWCOLORCANDLES plus zwei Linienbänder) über PlotIndexSetInteger. Die Logik wird nur bei geschlossenen Kerzen mit EMPTY_VALUE aktualisiert, um inaktive Bänder zu unterdrücken, wobei die Eingabeparameter atrPeriod und atrMultiplier für den Nutzer verfügbar gemacht werden. Sie erhalten ein sauberes, EA-fähiges Overlay mit dokumentierten Puffern für Strategien und Signale.
    Larry Williams‘ Marktgeheimnisse (Teil 9): Mit Mustern zum Gewinn Larry Williams‘ Marktgeheimnisse (Teil 9): Mit Mustern zum Gewinn
    Eine empirische Studie von Larry Williams' kurzfristigen Handelsmustern, die zeigt, wie klassische Setups in MQL5 automatisiert, an realen Marktdaten getestet und auf Konsistenz, Rentabilität und praktischen Handelswert bewertet werden können.
    MQL5-Handelswerkzeuge (Teil 13): Entwicklung eines Canvas-basierten Kurs-Dashboards mit Chart- und Statistik-Panels MQL5-Handelswerkzeuge (Teil 13): Entwicklung eines Canvas-basierten Kurs-Dashboards mit Chart- und Statistik-Panels
    In diesem Artikel entwickeln wir in MQL5 ein Canvas-basiertes Kurs-Dashboard auf Basis der CCanvas-Klasse. Es erstellt interaktive Panels zur Visualisierung jüngster Kursverläufe und Kontostatistiken und unterstützt Hintergrundbilder, Nebeleffekte sowie Farbverlaufsfüllungen. Das System unterstützt das Verschieben und die Größenänderung per Mausereignisbehandlung sowie das Umschalten zwischen einem dunklen und einem hellen Design mit dynamischen Farbanpassungen sowie Bedienelemente zum Minimieren und Maximieren für eine effiziente Verwaltung des Charts.