Umstellung auf MQL5 Algo Forge (Teil 3): Verwendung externer Repositories für die eigenen Projekte

Einführung

Im zweiten Teil unserer Umstellung auf MQL5 Algo Forge haben wir uns darauf konzentriert, eine der wichtigsten Herausforderungen zu lösen - die Arbeit mit mehreren Repositories. Mit der Kombination aus dem Bibliotheksprojekt Adwizard und des Expert Advisors Simple Candles haben wir Probleme gefunden und erfolgreich gelöst, die hauptsächlich mit den Pfaden zur Dateieinbindung und der Zusammenführung von Zweigen zusammenhängen. Wir haben auch versucht, (soweit möglich) Instrumente des MetaEditors während des gesamten Arbeitsablaufs zu verwenden, von der Erstellung eines separaten Zweigs für Korrekturen bis zur Zusammenführung über einen „Pull Request“. Wo jedoch die Funktionalität von MetaEditor nicht ausreichte, wechselten wir zur Weboberfläche von MQL5 Algo Forge, zu einem externen Git-Client in Visual Studio Code oder zu Git-Konsolenbefehlen. Dies hat deutlich gezeigt, wie man selbst bei der individuellen Entwicklung die bewährten Git-Verfahren anwenden kann, um Ordnung und eine klare Historie der Änderungen im Projekt zu erhalten.

Aber das war nur die eine Seite: die Nutzung des Speichers als „geschlossenes“ Ökosystem, in dem der Entwickler Eigentümer aller verwendeten Repositories ist. Der logische nächste Schritt und einer der Hauptgründe für den Wechsel zu Git ist die Möglichkeit, öffentliche Repositories von anderen Community-Mitgliedern vollständig zu nutzen. Hier zeigt sich das wahre Potenzial der verteilten Entwicklung: die Möglichkeit, den Code von Drittanbietern einfach zu verbinden und zu aktualisieren, zu seiner Verbesserung beizutragen und komplexe Projekte aus vorgefertigten, gut getesteten Komponenten zusammenzustellen. 

In diesem Artikel wenden wir uns endlich dieser vielversprechenden, aber auch komplexeren Aufgabe zu: wie man Bibliotheken aus Drittanbieter-Repositories innerhalb von MQL5 Algo Forge praktisch verbindet und verwendet. Und zwar nicht „irgendwann in der Zukunft“, sondern schon jetzt, ohne die Weiterentwicklung der Repository-Tools von MetaEditor abzuwarten. 

Der Weg ist vorgezeichnet

In diesem Artikel werden wir die Arbeit mit unserem Projektrepository Simple Candles fortsetzen, das als hervorragendes Testfeld für Experimente dienen wird. Die bestehende Handelsstrategie enthält bereits eine nutzerdefinierte Volatilitätsberechnung, die funktional dem Standardindikator Average True Range (ATR) ähnelt. Anstatt sich jedoch ausschließlich auf die eigene Implementierung zu verlassen, werden wir untersuchen, wie der Code durch die Einbeziehung spezialisierter, gebrauchsfertiger Lösungen aus der Gemeinschaft verbessert werden kann.

Zu diesem Zweck werden wir uns an das öffentlich zugängliche Repository SmartATR wenden, in der Annahme, dass es eine erweiterte und optimierte Version des Indikators enthält. Unser langfristiges praktisches Ziel ist es, den EA so zu modifizieren, dass er zwischen der weiteren Verwendung der internen Berechnung und dem Wechsel zum externen Bibliotheksalgorithmus von SmartATR wählen kann. In diesem Artikel werden wir uns jedoch nicht auf die Erstellung eines voll funktionsfähigen EA konzentrieren, sondern die wichtigsten Aspekte der Arbeit mit externen Repositories untersuchen.

Um dies zu erreichen, müssen wir Folgendes tun. Wir laden den Code der Bibliothek SmartATR auf unseren lokalen Rechner herunter und richten ihn für die Einbindung in unser Projekt ein. Wir zeigen Ihnen, wie Sie ein externes Repository in Ihre Arbeitsumgebung einbinden, sodass es später leicht aktualisiert werden kann, wenn neue Versionen veröffentlicht werden. Danach werden wir Änderungen sowohl am Projekt Simple Candles als auch (wie es sich als notwendig herausstellt) am Code der Bibliothek SmartATR selbst vornehmen. Idealerweise könnten wir den letzten Schritt vermeiden, aber da unser Fall dies erfordert, werden wir dies als praktisches Beispiel dafür verwenden, wie man Änderungen in das Repository eines anderen einführt. Schließlich werden wir die Integration verifizieren, indem wir testen, ob die Bibliothek SmartATR erfolgreich in unser Projekt eingebunden und kompiliert werden kann.

Dieser Ansatz ermöglicht es uns, den gesamten Prozess der Integration von externem Code sorgfältig zu durchlaufen. Die Erfahrung wird universell sein: Sobald wir eine Bibliothek erfolgreich hinzugefügt haben, werden wir in der Lage sein, jedes andere öffentliche Repository von MQL5 Algo Forge mit dem gleichen Ansatz in unsere Projekte einzubinden.

Einholen von externem Code

Auf den ersten Blick sollte dies kein Problem darstellen. Jedes Git-Repository kann mit dem Standard-Konsolenbefehl auf einen lokalen Computer geklont werden:

git clone ...

Wir haben uns jedoch darauf geeinigt, eine bestimmte Reihenfolge einzuhalten: Zuerst versuchen wir, über die MetaEditor-Schnittstelle zu arbeiten, dann über die Weboberfläche von MQL5 Algo Forge, und erst wenn diese Ansätze fehlschlagen, greifen wir auf externe Hilfsmittel wie Visual Studio Code oder den Konsolenbefehlen von Git zurück.

Die erste Frage lautet also: Wie können wir das Repository eines anderen Nutzers in MetaEditor anzeigen, um es zum Klonen auszuwählen? Die Teilantwort könnte in der Dokumentation der Anleitung zu finden sein, aber nur sehr wenige Nutzer wissen auf Anhieb, wo sie suchen müssen. Wir selbst sind erst später auf diese Seite gestoßen. Zuvor hatten wir festgestellt, dass der Ordner „Shared Projects“ in MetaEditor nur unsere eigenen Repositories anzeigt. Um dies weiter zu untersuchen, haben wir die Optionen des Kontextmenüs für diesen Ordner im Navigator von MetaEditor ausprobiert. 

Die Option Neues Projekt ist hier nicht die richtige, da sie nur ein neues Repository in unserem Besitz erstellt. Beim Aktualisieren werden auch keine externen Repositories hinzugefügt. Die Option „Alle Dateien anzeigen“ verhält sich seltsam: Nachdem sie ausgeführt wurde, erschienen doppelte Namen für unsere Repositories, die noch nicht lokal geklont worden waren. Glücklicherweise werden diese doppelten Namen durch Drücken von Aktualisieren entfernt. Unsere letzte Hoffnung war die Option „Alle öffentlichen Projekte anzeigen“, die ebenfalls keine sichtbaren Änderungen brachte.

Leider bedeutet dies, dass wir uns im Moment nicht ausschließlich auf MetaEditor verlassen können, um externe Repositories zu klonen. Schauen wir uns einige alternative Ansätze an, um unser Ziel zu erreichen.

Ansatz Eins: Direktes Klonen

Lassen Sie uns mit einem Experiment beginnen. Wenn wir einen leeren Ordner mit einem beliebigen Namen (z. B. TestRepo) innerhalb von Shared Projects erstellen, wird er in MetaEditor sichtbar. Von dort aus können wir sogar den Befehl Klonen über das Kontextmenü ausführen. Den Protokollen nach zu urteilen, versucht MetaEditor dann jedoch, ein Repository mit demselben Namen (TestRepo) aus unserem persönlichen Speicher zu klonen – ein Repository, das natürlich nicht existiert:

Dies bestätigt, dass die Methode nicht funktioniert, wenn man das Repository eines anderen klonen will. Versuchen wir stattdessen, das Repository SmartATR mit dem Konsolenbefehl „git clone ...“ direkt in Shared Projects zu klonen, um zu sehen, was passiert.

Nach dem Klonen erscheint ein neuer SmartATR-Ordner in Shared Projects und wird im Navigator von MetaEditor angezeigt. Noch wichtiger ist, dass wir dieses Repository nicht nur ansehen, sondern auch mit ihm arbeiten können: Wir können direkt von MetaEditor aus Pulls durchführen und den Änderungsverlauf (Log) einsehen.

Was MetaEditor also derzeit fehlt, ist eine Kontextmenü-Option wie „Clone from...“, die es dem Nutzer erlauben würde, die URL eines Repositories aus dem Speicher anzugeben oder alternativ einen Dialog zu öffnen, um alle öffentlichen Repositories in MQL5 Algo Forge zu suchen und auszuwählen (ähnlich wie der Abschnitt Explore in der Weboberfläche). Eine weitere Verbesserung könnte darin bestehen, dass nicht nur persönliche Repositories unter Shared Projects angezeigt werden, sondern auch öffentliche Repositories, die der Nutzer in der Weboberfläche mit einem Stern versehen hat (Starred Repositories), mit der Möglichkeit, ihre Sichtbarkeit umzuschalten. Aber lassen Sie uns nicht zu sehr darüber spekulieren, welche Änderungen letztendlich in MetaEditor eingeführt werden könnten.

Wenn wir nun zu unserem erfolgreich geklonten SmartATR-Repository zurückkehren, können wir sagen, dass das unmittelbare Ziel erreicht wurde. Der Quellcode des Projekts ist jetzt lokal verfügbar, was bedeutet, dass wir ihn in unseren eigenen Projekten verwenden können. Es gibt jedoch einen Vorbehalt. Wir können nur dann mit der direkten Nutzung fortfahren, wenn der SmartATR-Code keine Änderungen erfordert, d. h. wir können ihn „out of the box“ verwenden und nur aktualisieren, wenn neue Versionen veröffentlicht werden. Mal sehen, ob wir das hinkriegen.

Überprüfung der Funktionsfähigkeit

Im Rahmen des SmartATR-Projekts erhielten wir eine Datei mit dem Quellcode für einen MetaTrader 5-Indikator, der (laut Beschreibung) den Average True Range (ATR) mit einem fortschrittlicheren Ansatz berechnet. Versuchen wir, es zu kompilieren... und wir stoßen sofort auf einen Fehler. 

Unabhängig davon, wie schwerwiegend der Fehler ist, ist es wichtig, dass wir das Projekt nicht verwenden können, ohne Änderungen vorzunehmen. In diesem Stadium müssen wir entscheiden, ob wir die Korrekturen nur für unseren eigenen Gebrauch anwenden oder ob wir sie weitergeben und zum ursprünglichen Repository beitragen wollen. Andere Entwickler könnten auf das gleiche Problem stoßen, wenn sie versuchen, Code aus diesem Projekt zu verwenden. Daher ist die zweite Option vorzuziehen, da sie mit der Philosophie der Open-Source-Entwicklung übereinstimmt.

Gehen wir jedoch vorerst davon aus, dass wir derzeit keine Korrekturen veröffentlichen werden. Zunächst einmal müssen wir die Fehler beheben, erst dann können wir etwas Sinnvolles veröffentlichen. In diesem Fall, wenn wir nur lokale Änderungen am SmartATR-Projekt vornehmen wollen, können wir einfach einen neuen lokalen Zweig erstellen. 

Versuchen wir dies zu tun. Das ursprüngliche SmartATR-Repository enthält nur einen Hauptzweig, also erstellen wir einen neuen Entwicklungszweig über das Kontextmenü des Projektordners in MetaEditor. Der Zweig erscheint in der Liste der Zweige, die in MetaEditor angezeigt wird. Nach dem Drücken von Push bestätigen die Protokolle, dass der Vorgang erfolgreich war. Zu diesem Zeitpunkt kann man davon ausgehen, dass der neue Zweig im ursprünglichen Repository erstellt wurde. Die Überprüfung der Weboberfläche von MQL5 Algo Forge zeigt jedoch das Gegenteil: Es hat sich nichts geändert.

Als Nächstes wollen wir versuchen, den Code zu bearbeiten und die Änderungen von MetaEditor aus zu übernehmen. Wir fügen vor jeder Zeile, die einen Fehler verursacht hat, einen Kommentar ein, in dem wir auf die Notwendigkeit von Korrekturen hinweisen, und übertragen diese Änderungen. Aus den MetaEditor-Protokollen geht hervor, dass sowohl der Commit als auch der Push erfolgreich waren.

Wenn wir das ursprüngliche Repository in der Weboberfläche von MQL5 Algo Forge noch einmal überprüfen, sehen wir, dass sich nichts geändert hat. Dies ist zumindest ungewöhnlich. Schauen wir uns das Projekt in Visual Studio Code an und versuchen zu verstehen, was hier passiert. Wir öffnen den Ordner mit unserem SmartATR-Projektklon und sehen Folgendes:

Der letzte Commit existiert, aber VS Code schlägt vor, dass wir den Entwicklungszweig veröffentlichen. Das bedeutet, dass der Zweig noch nicht im entfernten Repository existiert und auch unsere Übergabe nicht. Wir versuchen, den Zweig zu veröffentlichen, erhalten aber eine Fehlermeldung:

Prüfen wir die Protokolle, um die Ursache herauszufinden:

Unser Nutzerkonto hat keine Schreibberechtigung für das ursprüngliche Repository. Das macht Sinn. Andernfalls könnte das Projekt leicht im Chaos versinken, wenn jeder unkontrollierte Änderungen vornimmt. Das bedeutet, dass wir nur in unserer lokalen Kopie Änderungen vornehmen können. Diese Änderungen können jedoch nicht mit dem entfernten System synchronisiert werden und sind nur in unserem lokalen Klon vorhanden. Das ist alles andere als ideal. Neben den Optionen für die Zusammenarbeit spielen externe Repositories eine sehr wichtige Rolle – sie dienen als Speicher für Projekt-Backups. Es wäre unklug, dieses Sicherheitsnetz aufzugeben.

Es ist auch erwähnenswert, dass es bei der ausschließlichen Arbeit in MetaEditor keinen Hinweis darauf gab, dass etwas nicht in Ordnung war. Den MetaEditor-Protokollen zufolge schien alles in Ordnung zu sein: keine Fehler, und alle Änderungen wurden „erfolgreich“ in ein nicht existierendes Repository übertragen.... Es bleibt zu hoffen, dass dieses Problem in zukünftigen Versionen behoben wird.

Ansatz zwei: Klonen eines Fork

Versuchen wir nun einen anderen Weg. Auch hier müssen wir über die aktuellen Möglichkeiten von MetaEditor hinausgehen – dieses Mal werden wir zusätzlich die Weboberfläche von MQL5 Algo Forge verwenden. Für Entwickler, die Git-Befehlszeilenoperationen als schwierig empfinden, stellt dies einen Kompromiss dar. In der Weboberfläche von MQL5 Algo Forge können wir das gewünschte Original-Repository forken. 

Fork ist ein grundlegendes Konzept in Versionskontrollsystemen und kollaborativen Entwicklungsplattformen, einschließlich MQL5 Algo Forge. Darunter versteht man den Prozess der Erstellung einer vollständigen und unabhängigen Kopie des ursprünglichen Repositories innerhalb der Plattform.

Wenn ein Nutzer das Repository eines anderen Nutzers forkt, erstellt die Plattform eine exakte Kopie unter dem Konto des Nutzers. Diese Kopie erbt den gesamten Änderungsverlauf, die Zweige und Dateien des Quellprojekts zum Zeitpunkt des Forkens, wird aber von diesem Moment an zu einem eigenständigen Repository. Der neue Eigentümer kann sie frei verändern, ohne das Original zu beeinträchtigen.

Ein Fork ermöglicht es also jedem Nutzer, auf einem bestehenden Projekt aufzubauen und es auf seinem eigenen Weg weiterzuentwickeln, wodurch ein neuer Entwicklungszweig für den Code entsteht. Dieses Konzept ermöglicht die Schaffung von abgeleiteten Projekten und alternativen Implementierungen innerhalb des Open-Source-Ökosystems.

Forks sind auch das wichtigste Mittel, um Änderungen an Projekten vorzunehmen, auf die der Nutzer keinen direkten Schreibzugriff hat. Der Standard-Workflow ist folgender: Erstellen Sie einen Fork, implementieren und testen Sie die gewünschten Änderungen darin, und informieren Sie dann den Betreuer des ursprünglichen Repositories über die vorgeschlagenen Verbesserungen mittels eines Pull Request, den wir bereits in Teil 2 behandelt haben. Dies ist die Grundlage des Modells der dezentralen Entwicklungszusammenarbeit.

Trotz ihrer Unabhängigkeit behalten Forks eine technische Verbindung zum Quell-Repository. Dadurch ist es möglich, Änderungen im Original zu verfolgen und sie mit Ihrem Fork zu synchronisieren, indem Sie neue Commits aus dem Upstream-Projekt in Ihr eigenes Projekt einbringen.

Es ist wichtig, zwischen einem Fork und einem einfachen Klon zu unterscheiden. Klonen bedeutet, eine lokale Kopie eines Repositories auf einem bestimmten Computer zu erstellen, während ein Fork eine vollständige Kopie auf der Plattform selbst ist, die ein neues entferntes Repository unter dem Besitz eines anderen Nutzers einrichtet.

Sobald wir also ein Repository forken, wird es zu unserem eigenen Repository. Es wird auch in der Liste „Shared Projects“ in MetaEditor sichtbar und kann direkt über MetaEditor geklont werden.

Testen der Arbeit mit einem Fork

Dank der freundlichen Unterstützung von Fernando Carreiro konnten wir diesen Mechanismus in der Praxis testen. Wir haben sein Repository FMIC geforkt und gleichzeitig das ursprüngliche Repository zu unseren Watch- und Starred-Listen im MQL5 Algo Forge Webinterface hinzugefügt.

Wie erwartet erschien der Fork in der Liste der Repositories, die unter Shared Projects in MetaEditor angezeigt wurde:

Dadurch konnten wir unser neu erstelltes Fork des Repositories FMIC erfolgreich auf den lokalen Computer klonen.

Als Nächstes baten wir Fernando, einige Änderungen zu übertragen, damit wir testen konnten, wie sich die Aktualisierungen in unserem Fork auswirken würden. Er fügte eine README.md-Beispieldatei hinzu, die die Publikation Heikin Ashi beschreibt, und übertrug sie in das Repository.

Danach wurde in der Weboberfläche tatsächlich eine Benachrichtigung über die neuen Änderungen angezeigt:

Diese Meldungen wirkten sich jedoch noch nicht auf unseren auf MQL5 Algo Forge gespeicherten Fork oder den lokalen Klon auf unserem Computer aus. Lassen Sie uns versuchen, Fernandos Änderungen in unsere Repositories zu übernehmen. Zunächst prüfen wir, ob die letzten Änderungen in unserem lokalen Klon tatsächlich fehlen:

Die letzte Übertragung in unsere lokale Historie datiert vom 27. August 2025, während die Änderungen von Fernando danach vorgenommen wurden.

Wenn wir nun unseren Fork in der Weboberfläche besuchen, sehen wir eine Meldung, dass unser Hauptzweig drei Commits hinter dem ursprünglichen Repository liegt:

Wir sehen auch eine Schaltfläche Sync, die unseren Hauptordner mit dem Upstream-Zweig synchronisieren soll. Wir überprüfen dann die Historie der Commits und sehen drei neue Commits vom 5. September 2025, die vorher nicht vorhanden waren:

Mit anderen Worten, alle im ursprünglichen Repository vorgenommenen Änderungen wurden erfolgreich zuerst in unseren Fork auf MQL5 Algo Forge und dann in unseren lokalen Klon dieses Forks übertragen.

Für diejenigen, die diesen Mechanismus genauer erforschen möchten, empfehlen wir, die folgenden GitHub-Dokumentationsabschnitte zu konsultieren: 

• Forken eines Repositories
• Konfigurieren eines entferntes Repositories
• Synchronisieren

Obwohl diese Dokumentation nicht speziell für MQL5 Algo Forge geschrieben wurde, verhält sich ein Großteil der Weboberfläche ähnlich, und die Git-Konsolenbefehle sind unabhängig von der Hosting-Plattform universell anwendbar. Vorausgesetzt natürlich, dass die Plattform auf Git basiert.

Wenn wir beispielsweise die KonfigurationsrichtlinienKonfiguration des Upstreams folgen, können wir die Synchronisation so einrichten, dass jede Pull/Push-Operation auch unseren Fork-Klon gegen das Original-Repository aktualisiert:

Wenn Sie jedoch ausschließlich mit MetaEditor und der Weboberfläche von MQL5 Algo Forge arbeiten, ist dieser zusätzliche Konfigurationsschritt nicht unbedingt erforderlich.

Forking SmartATR

Kehren wir nun zu dem Repository zurück, das wir ursprünglich verwenden wollten. Wir wiederholen dieselben Schritte – Erstellen eines Forks über die Weboberfläche von MQL5 Algo Forge und lokales Klonen – für das SmartATR-Repository.

Wir beginnen mit der Suche nach dem ursprünglichen Repository im Abschnitt Explore, indem wir seinen Namen eingeben:

Da das Repository bereits mehrere Forks enthält, die von anderen Nutzern erstellt wurden, werden in den Suchergebnissen auch diese Forks angezeigt. Um das echte Original zu finden, scrollen wir weiter nach unten und öffnen die Seite steverosenstock/SmartATR.

Dort klicken wir auf die Schaltfläche Fork:

Nach dem Anklicken werden wir zur Seite mit den Einstellungen für die Gabelung weitergeleitet. Hier können wir das geforkte Repository umbenennen (so wie es in unserer Liste der Repositories erscheinen wird), angeben, welche Zweige des Originals einbezogen werden sollen, und die Repository-Beschreibung bearbeiten, falls gewünscht:

Standardmäßig wird der Fork als exakte Kopie des ursprünglichen Repositories erstellt. Das funktioniert für uns perfekt, also klicken wir einfach auf „Fork repository“.

Der Zweig wurde erfolgreich erstellt:

Als nächstes klonen wir dieses Repository auf unseren lokalen Computer. Zuvor löschen wir den zuvor geklonten Original-SmartATR-Ordner auf dem lokalen Computer. Wenn MetaEditor bereits geöffnet war, müssen wir die Ordnerliste aktualisieren, indem wir Refresh aus dem Kontextmenü Shared Projects wählen. Danach erscheint der Ordner SmartATR, aus dessen Kontextmenü wir „Git Clone“ auswählen: 

Das SmartATR-Projekt wurde erfolgreich geklont:

Wir sind jetzt bereit, mit den Veränderungen zu beginnen.

Änderungen vornehmen

Da unser Ziel darin besteht, Korrekturen einzuführen, die einen bestimmten Fehler entweder beheben oder zumindest neutralisieren, beginnen wir mit der Erstellung eines neuen Zweigs, dessen Name diesen Zweck deutlich widerspiegelt; zum Beispiel: fixes/news-impact:

Anschließend wechseln wir im Kontextmenü des Projekts zu diesem Zweig, indem wir „Git Branches → fixes-news-impact“ wählen.

Beachten Sie, dass wir zwar ursprünglich einen Schrägstrich („/“) in den Namen der Verzweigung aufgenommen haben, die Verzweigung jedoch so erstellt wurde, dass dieses Zeichen automatisch durch einen Bindestrich („-“) ersetzt wurde. Dies ist eine Einschränkung von MetaEditor, der nur lateinische Buchstaben und Bindestriche in Zweignamen zulässt. Technisch gesehen erlaubt Git selbst Schrägstriche, und über die Weboberfläche können wir frei Zweige erstellen, die diese enthalten. 

Testen wir, wie wichtig diese Einschränkung ist. Wir erstellen einen weiteren Zweig direkt in der MQL5 Algo Forge Weboberfläche, diesmal mit einem expliziten Schrägstrich in seinem Namen: fixes/cast-warning. Auf der Seite Branches wählen wir „New branch“ und verwenden den Hauptzweig als Basis:

Der Zweig wurde erfolgreich erstellt:

Wenn wir jedoch versuchen, einen Pull in MetaEditor auszuführen, erhalten wir eine Fehlermeldung:

Trotzdem erscheint der neue Zweig mit dem Schrägstrich in seinem Namen in der Zweigliste im MetaEditor, und der Wechsel zu ihm funktioniert ohne weitere Probleme:

Nachdem wir diese Besonderheit zur Kenntnis genommen haben, wechseln wir zurück zum Zweig fixes-news-impact und führen die temporäre Korrektur ein, die die Ursache des Kompilierungsfehlers beseitigt:

Sobald der Indikator ohne Fehler kompiliert wurde, übertragen wir unsere Änderungen über die Kontextmenüoption „Git Commit“: 

Im Übermittlungsdialog überprüfen wir die Liste der geänderten Dateien. Die Prüfung ist in diesem Fall einfach, da wir nur eine Datei geändert haben. Es wird dringend empfohlen, einen beschreibenden Kommentar hinzuzufügen, der die Art der Korrektur erläutert. Nachdem wir bestätigt haben, dass alles korrekt ist, drücken wir auf OK.

Unsere Änderungen sind nun festgeschrieben und in unseren Fork des SmartATR-Repository in der MQL5 Algo Forge eingefügt. In diesem Stadium kann die korrigierte Version des Indikators bereits lokal verwendet werden, wobei eine sichere Kopie auch im Repository gespeichert ist. Optional können wir einen Pull Request an den ursprünglichen Projektautor senden, indem wir in der Weboberfläche des Repositories auf „New pull request“ klicken:

Es ist jedoch noch zu früh, da unsere Änderung lediglich einen Teil der Funktionalität deaktiviert, anstatt den Code zu verbessern. Im Moment erstellen wir noch keinen Pull-Request.

Der SmartATR-Indikator ist bereit, in unser Simple Candles-Projekt integriert zu werden.

Einbindung des Indikators

Gemäß den Best Practices erstellen wir einen neuen Zweig im Simple Candles-Projekt-Repository – article-19436-forge3 – basierend auf dem Entwicklungszweig. Um unseren Ansatz zu variieren, erstellen wir diesen Zweig mit Hilfe der Weboberfläche von MQL5 Algo Forge.

Damit der Zweig lokal erscheint, führen wir „Git Pull“ in MetaEditor aus und wechseln dann zum neuen Zweig article-19436-forge3.

Da wir beabsichtigen, den Indikator innerhalb der Handelsstrategie anzuwenden, fügen wir ihn direkt zur Implementierung der Strategieklasse in SimpleCandlesStrategy.mqh hinzu. Konkret führen wir ein Feld der Klasse ein, in dem der Indikator-Handle gespeichert wird:

//+------------------------------------------------------------------+
//| Trading strategy using unidirectional candlesticks               |
//+------------------------------------------------------------------+
class CSimpleCandlesStrategy : public CVirtualStrategy {
protected:
   //...

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

Als Nächstes rufen wir iCustom() im Klassenkonstruktor auf und übergeben das gewünschte Symbol, den Zeitrahmen, den Pfad zur Indikatordatei und seine Parameter:

//+------------------------------------------------------------------+
//| Constructor                                                      |
//+------------------------------------------------------------------+
CSimpleCandlesStrategy::CSimpleCandlesStrategy(string p_params) {
// Read the parameters from the initialization string
   // ...

   if(IsValid()) {
      // Load the SmartATR indicator
      m_iATRHandle = iCustom(
                        m_symbol, m_timeframe,
                        "Shared Projects/SmartATR/SmartATR.ex5",
                        // Indicator parameters
                        m_periodATR,   // Initial ATR period (used for first calculation, adaptively changes)
                        false,         // Enable adaptive period (dynamic lookback)
                        7,             // Minimum ATR period (adaptive mode)
                        28,            // Maximum ATR period (adaptive mode)
                        false,         // Weight True Range by volume
                        false,         // Weight True Range by economic news events (MT5 Calendar)
                        2.0,           // Multiplier: alert if ATR exceeds this factor of average
                        false          // Enable pop-up & sound alerts on high volatility
                     );

      // ...
   }
}

Beachten Sie den für den Indikator angegebenen Pfad. Wir beginnen mit Shared Projects, dann folgt der Name des Projektordners SmartATR, gefolgt von dem Dateinamen des Indikators SmartATR.ex5. Das Einfügen der Erweiterung .ex5 ist optional, aber es hilft, Verwechslungen zu vermeiden.

Es gibt eine wichtige Nuance, die bei der Arbeit im Ordner Shared Projects beachtet werden sollte. Dies bezieht sich sowohl auf Ihre eigenen als auch auf geforkte Projekte. Alle kompilierten ausführbaren Dateien werden nicht direkt im Repository-Ordner abgelegt. Das liegt daran, dass sich der Ordner „Shared Projects“ im Stammordner der Terminaldaten befindet: MQL5/Shared Projects. Einerseits ist dies gut, da das Versionskontrollsystem nicht versuchen wird, die Indizierung ausführbarer Dateien vorzuschlagen. Andererseits kann es anfangs etwas verwirrend sein: Wo finden wir die kompilierten Expert Advisor- und Indikator-Dateien?

Sie werden in ihren jeweiligen Standardordnern erstellt, z. B. MQL5/Experts für EAs oder MQL5/Indicators für Indikatoren. Innerhalb dieser Verzeichnisse wird automatisch ein Unterverzeichnis Shared Projects erstellt. Die kompilierten Dateien werden also direkt in diesen Unterordnern erstellt. Das bedeutet, dass das Kompilieren einer Datei aus MQL5/Shared Projects/SmartATR.mq5 die ausführbare Datei unter MQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5 erzeugt.

Dementsprechend muss der Aufruf von iCustom() den Indikatorpfad relativ zu MQL5/Indicators referenzieren.

Schließlich kompilieren wir die Datei des Advisors SimpleCandles.mq5 und führen sie im Strategietester aus. Die Protokolle zeigen Folgendes:

Der SmartATR-Indikator wurde also erfolgreich geladen, initialisiert und ist einsatzbereit. Zum jetzigen Zeitpunkt demonstrieren wir lediglich seine Integration. Die tatsächliche Verwendung innerhalb der Strategielogik könnte später hinzugefügt werden. Wir übertragen diese Änderungen und schieben sie in das MQL5 Algo Forge Repository.

Schlussfolgerung

Dieser Artikel zeigt, wie die Übernahme von MQL5 Algo Forge einen grundlegend flexibleren Arbeitsablauf für Entwickler ermöglicht. Bisher haben wir nur in sich geschlossene Repositories untersucht, aber hier haben wir erfolgreich eine externe Bibliothek aus einem Drittanbieter-Repository in unser Projekt integriert.

Der Schlüsselmoment war der richtige Arbeitsablauf, der auf dem Forking basiert – dem Erstellen einer persönlichen Kopie eines externen Repositories, das vollständige Änderungen erlaubt, während es mit dem Upstream-Projekt synchronisiert bleibt. Die erfolgreiche Integration von SmartATR in Simple Candles unterstützt diesen Ansatz – vom Auffinden und Forken des Repositories bis hin zum Ändern und Anwenden des Codes in einer Live-Handelsstrategie.

Wichtig ist, dass dieser Prozess vollständig mit den aktuellen MetaEditor-Funktionen durchgeführt werden konnte, ohne auf zukünftige Updates zu warten. Die Einschränkungen von MetaEditor (wie z.B. der fehlende direkte Zugriff auf Repositories von Drittanbietern und die eingeschränkte Benennung von Zweigen) lassen sich leicht überwinden, indem man es mit der Weboberfläche von MQL5 Algo Forge und, falls erforderlich, mit Standardbefehlen der Git-Konsole ergänzt. Kurz gesagt, das System ist bereits praxistauglich, und die verbleibenden Schnittstellenmängel sind eher lästig als hinderlich.

Jedoch sollten wir dabei stehen bleiben. Wir werden weiterhin Repositories verwenden, um Projekte voneinander zu trennen und unsere Erfahrungen auszutauschen, die wir auf diesem Weg gesammelt haben.

Vielen Dank für Ihre Aufmerksamkeit! Bis bald!