Passaggio a MQL5 Algo Forge (Parte 3): Utilizzo di Repository Esterni nei Propri Progetti

Introduzione

Nella seconda parte della nostra transizione a MQL5 Algo Forge, ci siamo concentrati sulla risoluzione di una delle sfide più importanti - lavorare con più repository. Utilizzando la combinazione del progetto di libreria Adwizard e l'Expert Advisor Simple Candles, abbiamo riscontrato e risolto con successo problemi legati soprattutto ai percorsi di inclusione dei file e all'unione dei rami. Abbiamo anche cercato di utilizzare gli strumenti di MetaEditor (ove possibile) durante l'intero flusso di lavoro, dalla creazione di un ramo separato per le correzioni all'unione tramite una Pull Request. Tuttavia, quando la funzionalità di MetaEditor non era sufficiente, siamo passati all'interfaccia web di MQL5 Algo Forge, a un client Git esterno in Visual Studio Code o ai comandi della console Git. Questo ha dimostrato chiaramente come anche nello sviluppo individuale si possano applicare le best practice di Git per mantenere l'ordine e una chiara cronologia delle modifiche all'interno del progetto.

Ma questo era solo un aspetto: l'utilizzo dello storage come ecosistema "chiuso" in cui lo sviluppatore è proprietario di tutti i repository utilizzati. Il logico passo successivo e uno dei motivi principali per cui si è passati a Git, è la possibilità di sfruttare appieno i repository pubblici di altri membri della community. È qui che si rivela il vero potenziale dello sviluppo distribuito: la possibilità di collegare e aggiornare facilmente il codice di terzi, di contribuire al suo miglioramento e di assemblare progetti complessi a partire da componenti già pronti e ben collaudati. 

In questo articolo ci occupiamo finalmente di questo promettente, ma più complesso, compito: come collegare e utilizzare praticamente le librerie di repository di terze parti all'interno di MQL5 Algo Forge. E non "un giorno in futuro", ma proprio ora, senza aspettare un ulteriore sviluppo degli strumenti di MetaEditor. 

Mappatura del Percorso

In questo articolo continueremo a lavorare con il nostro repository del progetto Simple Candles, che servirà da ottimo terreno di prova per la sperimentazione. La strategia di trading esistente include già un calcolo personalizzato della volatilità, funzionalmente simile all'indicatore standard Average True Range (ATR). Tuttavia, invece di affidarci esclusivamente alla nostra implementazione, esploreremo come migliorare il codice includendo soluzioni specializzate e pronte all'uso provenienti dalla comunità.

A tal fine, ci rivolgeremo al repository pubblico disponibile SmartATR, supponendo che contenga una versione più avanzata e ottimizzata dell'indicatore. Il nostro obiettivo pratico a lungo termine è quello di modificare l'EA in modo che possa scegliere se continuare a utilizzare il calcolo interno o passare all'algoritmo esterno della libreria SmartATR. Tuttavia, in questo articolo non ci concentreremo sulla costruzione di un EA completamente funzionale, ma esamineremo invece gli aspetti chiave del lavoro con i repository esterni.

Per ottenere questo risultato, è necessario procedere come segue. Scaricare il codice della libreria SmartATR sul computer locale e impostarlo per l'inclusione nel nostro progetto. Parleremo di come aggiungere un repository esterno al vostro ambiente di lavoro, in modo da poterlo aggiornare facilmente quando vengono rilasciate nuove versioni. Dopodiché, applicheremo le modifiche sia al progetto Simple Candles che (come si è rivelato necessario) al codice della libreria SmartATR stessa. L'ideale sarebbe evitare l'ultimo passaggio, ma poiché il nostro caso lo richiede, lo useremo come esempio pratico di come introdurre modifiche nel repository di qualcun altro. Infine, verificheremo l'integrazione testando se la libreria SmartATR può essere inclusa e compilata con successo come parte del nostro progetto.

Questo approccio ci consentirà di seguire attentamente l'intero processo di integrazione del codice esterno. L'esperienza sarà universale: una volta aggiunta con successo una libreria, saremo in grado di includere qualsiasi altro repository pubblico da MQL5 Algo Forge nei nostri progetti utilizzando lo stesso approccio.

Ottenere il Codice Esterno

A prima vista, questo non dovrebbe rappresentare un problema. Qualsiasi repository Git può essere clonato su un computer locale usando il comando standard della console:

git clone ...

Tuttavia, abbiamo deciso di seguire un ordine specifico: prima provare a lavorare attraverso l'interfaccia di MetaEditor, poi l'interfaccia web di MQL5 Algo Forge e solo se questi approcci falliscono, ricorrere a strumenti esterni come Visual Studio Code o ai comandi della console Git.

Quindi la prima domanda è: come si fa a visualizzare il repository di qualcun altro in MetaEditor per selezionarlo per la clonazione? La risposta parziale potrebbe essere trovata nella documentazione della guida, ma pochi utenti saprebbero subito dove cercare. Noi stessi ci siamo imbattuti in questa pagina solo in un secondo momento. In precedenza, avevamo notato che la cartella Shared Projects (Progetti Condivisi) di MetaEditor mostrava solo i nostri repository. Per indagare ulteriormente, abbiamo provato le opzioni del menu contestuale disponibili per questa cartella nel Navigatore di MetaEditor. 

L'opzione Nuovo Progetto non è quella giusta, perché crea solo un nuovo repository di nostra proprietà. L'aggiornamento non aggiunge nemmeno repository esterni. L'opzione "Mostra tutti i file" si comporta in modo strano: dopo averla eseguita, sono apparsi nomi duplicati per i nostri repository che non erano ancora stati clonati localmente. Fortunatamente, premendo Aggiorna si eliminano questi nomi duplicati. L'ultima speranza era l'opzione "Mostra Tutti i Progetti Pubblici", ma anche questa non ha prodotto cambiamenti visibili.

Sfortunatamente, questo significa che per ora non possiamo fare affidamento solo su MetaEditor per clonare i repository esterni. Vediamo un paio di approcci alternativi per raggiungere il nostro obiettivo.

Primo Approccio: Clonazione Diretta

Iniziamo con un esperimento. Se creiamo una cartella vuota con un nome qualsiasi (ad esempio, TestRepo) all'interno di Progetti Condivisi, questa diventa visibile in MetaEditor. Da qui si può anche eseguire il comando Clone dal menu contestuale. Tuttavia, a giudicare dai log, MetaEditor tenta di clonare un repository con lo stesso nome(TestRepo) dal nostro archivio personale - un repository che, ovviamente, non esiste:

Questo conferma che il metodo non funziona per clonare il repository di qualcun altro. Proviamo invece a clonare il repository SmartATR direttamente in Progetti Condivisi (Shared Projects) usando il comando da console 'git clone ...' e vediamo cosa succede.

Dopo la clonazione, una nuova cartella SmartATR appare in Progetti Condivisi e viene visualizzata nel Navigatore di MetaEditor. Inoltre, possiamo non solo visualizzare questo repository, ma anche lavorarci come un repository: eseguire Pull e visualizzare la cronologia delle modifiche (Log) direttamente da MetaEditor.

Pertanto, ciò che attualmente manca a MetaEditor è un'opzione del menu contestuale come "Clona da...", che consentirebbe all'utente di specificare l'URL di un repository dall’archivio o in alternativa, di aprire una finestra di dialogo per cercare e selezionare tra tutti i repository pubblici in MQL5 Algo Forge (simile alla sezione Esplora nell'interfaccia web). Un altro possibile miglioramento potrebbe essere quello di visualizzare non solo i repository personali sotto la voce Progetti Condivisi, ma anche i repository pubblici che l'utente ha salvato nell'interfaccia web (Repository Salvati), con la possibilità di alternarne la visibilità. Ma non facciamo troppe ipotesi su quali cambiamenti potrebbero eventualmente essere introdotti in MetaEditor.

Per ora, tornando al nostro repository SmartATR clonato con successo, possiamo dire che l'obiettivo immediato è stato raggiunto. Il codice sorgente del progetto è ora disponibile localmente, il che significa che possiamo utilizzarlo nei nostri progetti. Tuttavia, c'è una precisazione. Possiamo procedere all'utilizzo diretto solo se il codice di SmartATR non richiede modifiche, ovvero possiamo utilizzarlo "così com’è", aggiornandolo solo quando vengono rilasciate nuove versioni. Vediamo se riusciamo a farlo.

Verifica delle Funzionalità

Nell'ambito del progetto SmartATR, abbiamo ricevuto un file con il codice sorgente di un indicatore MetaTrader 5 che (secondo la descrizione) calcola l'Average True Range (ATR) utilizzando un approccio più avanzato. Proviamo a compilarlo... e incontriamo subito un errore. 

Indipendentemente dalla gravità dell'errore, il punto importante è questo: non possiamo utilizzare il progetto senza apportare modifiche. A questo punto, dobbiamo decidere se applicare le correzioni solo per il nostro uso locale o se condividerle e contribuire al repository originale. Anche altri sviluppatori potrebbero riscontrare lo stesso problema quando cercano di utilizzare il codice di questo progetto. Quindi, la seconda opzione è preferibile, in quanto si allinea alla filosofia dello sviluppo open-source.

Per ora, tuttavia, supponiamo che non pubblicheremo correzioni al momento. Prima di tutto, dobbiamo risolvere gli errori; solo allora avremo qualcosa di significativo da pubblicare. In questo caso, se intendiamo apportare solo modifiche locali al progetto SmartATR, possiamo semplicemente creare un nuovo ramo locale. 

Proviamo a farlo. Il repository originale di SmartATR contiene solo un ramo main, quindi creeremo un nuovo ramo develop tramite il menu contestuale della cartella del progetto in MetaEditor. Il ramo appare nell'elenco dei rami di MetaEditor. Dopo aver premuto Push, i registri confermano che l'operazione è andata a buon fine. A questo punto, ci si potrebbe aspettare che il nuovo ramo sia stato creato nel repository originale. Ma il controllo dell'interfaccia web di MQL5 Algo Forge mostra il contrario: nulla è cambiato.

Proviamo quindi a modificare il codice e a fare il commit delle modifiche da MetaEditor. Aggiungiamo dei commenti prima di ogni riga che ha causato un errore, segnalando la necessità di correggerla, e facciamo il commit di queste modifiche. I log di MetaEditor indicano che sia il commit che il push sono andati a buon fine.

Tuttavia, ancora una volta, controllando il repository originale nell'interfaccia web di MQL5 Algo Forge, vediamo che nulla è cambiato. Questo è quantomeno insolito. Controlliamo il progetto in Visual Studio Code e cerchiamo di capire cosa sta succedendo. Apriamo la cartella con il clone del progetto SmartATR e vediamo quanto segue:

L'ultimo commit esiste, ma VS Code suggerisce di pubblicare il ramo develop. Ciò significa che il ramo non esiste ancora nel repository remoto, né il nostro commit. Cerchiamo di pubblicare il ramo ma otteniamo un errore:

Controllare i registri per scoprire il motivo:

Il nostro account utente non ha i permessi di scrittura per il repository originale. Questo ha senso. In caso contrario, il progetto potrebbe facilmente degenerare nel caos con modifiche incontrollate da parte di chiunque. Ciò significa che possiamo apportare modifiche solo alla nostra copia locale. Tuttavia, queste modifiche non possono essere sincronizzate con il remoto e saranno presenti solo nel nostro clone locale. Questo è tutt'altro che ideale. Oltre alle opzioni di collaborazione, i repository esterni svolgono un ruolo molto importante - fungono da archivio di backup dei progetti. Rinunciare a questa rete di sicurezza non sarebbe saggio.

Vale anche la pena di notare che quando si lavorava esclusivamente in MetaEditor, non c'era alcuna indicazione che qualcosa non andasse. Secondo i log di MetaEditor, tutto sembrava a posto: nessun errore e tutte le modifiche sono state inviate "con successo"... a un repository inesistente. Si spera che questo problema venga corretto nelle prossime versioni.

Secondo Approccio: Clonazione di un Fork

Proviamo ora a percorrere una strada diversa. Anche in questo caso, dovremo uscire dalle capacità attuali di MetaEditor - questa volta utilizzeremo anche l'interfaccia web di MQL5 Algo Forge. Per gli sviluppatori che trovano impegnative le operazioni di Git da riga di comando, questa soluzione rappresenta un compromesso. Nell'interfaccia web di MQL5 Algo Forge, possiamo creare un fork del repository originale desiderato. 

Il fork è un concetto fondamentale nei sistemi di controllo delle versioni e nelle piattaforme di sviluppo collaborativo, incluso MQL5 Algo Forge. Si tratta del processo di creazione di una copia completa e indipendente del repository originale all'interno della piattaforma.

Quando un utente fa il fork di un repository altrui, la piattaforma crea una copia esatta sotto l'account dell'utente. Questa copia eredita tutta la cronologia delle modifiche, i rami e i file del progetto sorgente al momento della ramificazione, ma da quel momento in poi diventa un repository autonomo. Il nuovo proprietario può modificarlo liberamente senza intaccare l'originale.

Pertanto,un fork consente a qualsiasi utente di basarsi su un progetto esistente e di svilupparlo secondo il proprio percorso, creando di fatto un nuovo ramo di evoluzione del codice. Questo concetto consente di creare progetti derivati e implementazioni alternative all'interno dell'ecosistema open-source.

I fork sono anche il mezzo principale per contribuire alle modifiche dei progetti in cui l'utente non ha accesso diretto alla scrittura. Il flusso di lavoro standard è il seguente: si crea un fork, si implementano e si testano le modifiche richieste e si comunica al manutentore del repository originale i miglioramenti proposti tramite una Pull Request, di cui abbiamo già parlato nella seconda parte. Questa è la base del modello di sviluppo collaborativo decentralizzato.

Nonostante la loro indipendenza, i fork mantengono un legame tecnico con il repository di origine. In questo modo è possibile tenere traccia delle modifiche apportate all'originale e sincronizzarle con il proprio fork, unendo i nuovi commit del progetto a monte, al proprio.

È importante distinguere tra un fork e un semplice clone. La clonazione si riferisce alla creazione di una copia locale di un repository su un computer specifico, mentre il fork è una copia completa sulla piattaforma stessa, che crea un nuovo repository remoto sotto la proprietà di un altro utente.

Pertanto, una volta creato un fork di un repository, questo diventa il nostro repository personale. Diventa inoltre visibile nell'elenco dei Progetti Condivisi di MetaEditor e disponibile per la clonazione direttamente da MetaEditor.

Testare il Lavoro con un Fork

Grazie alla gentile assistenza di Fernando Carreiro, abbiamo potuto testare questo meccanismo nella pratica. Abbiamo fatto il fork del suo repository FMIC e allo stesso tempo abbiamo aggiunto il repository originale alle nostre liste Segui e Salva nell'interfaccia web di MQL5 Algo Forge.

Come previsto, il fork è apparso nell'elenco dei repository visualizzato in Progetti Condivisi in MetaEditor:

Questo ci ha permesso di clonare con successo il nostro fork FMIC sul computer locale.

Poi abbiamo chiesto a Fernando di effettuare i commit di alcune modifiche, in modo da poter verificare come gli aggiornamenti si sarebbero riflessi nel nostro fork. Ha aggiunto un file README.md di esempio che descrive la pubblicazione di Heikin Ashi e lo ha inviato al repository.

Successivamente, nell'interfaccia web è effettivamente comparsa una notifica delle nuove modifiche:

Tuttavia, queste notifiche non hanno ancora influenzato né il nostro fork memorizzato su MQL5 Algo Forge né il clone locale sul nostro computer. Proviamo a fare un pull delle modifiche di Fernando nei nostri repository. Per prima cosa, controlliamo che le ultime modifiche siano effettivamente assenti nel nostro clone locale:

L'ultimo commit nella nostra cronologia locale è datato 27 agosto 2025, mentre le modifiche di Fernando sono state apportate successivamente.

Ora, se visitiamo il nostro fork nell'interfaccia web, vediamo un messaggio che indica che il nostro ramo main è indietro di tre commit rispetto al repository originale:

Vediamo anche un pulsante Sync, che dovrebbe sincronizzare la nostra cartella main con il ramo a monte. Controlliamo quindi la cronologia dei commit e vediamo tre nuovi commit datati 5 settembre 2025, che prima erano assenti:

In altre parole, tutti i commit fatti nel repository originale si sono propagati con successo prima nel nostro fork su MQL5 Algo Forge e poi nel nostro clone locale di quel fork.

Per chi volesse approfondire questo meccanismo, consigliamo di consultare le seguenti sezioni della documentazione di GitHub: 

• Creare il fork di un repository
• Configurare un repository remoto
• Sincronizzare

Sebbene questa documentazione non sia stata scritta specificamente per MQL5 Algo Forge, gran parte dell'interfaccia web si comporta in modo simile e i comandi Git della console sono universalmente applicabili indipendentemente dalla piattaforma di hosting. A condizione, ovviamente, che la piattaforma sia basata su Git.

Per esempio, seguendo le linee guida della configurazione dell’originale, possiamo impostare la sincronizzazione in modo che ogni operazione di Pull/Push aggiorni anche il nostro fork clone rispetto al repository originale:

Tuttavia, quando si lavora esclusivamente attraverso MetaEditor e l'interfaccia web di MQL5 Algo Forge, questa fase di configurazione aggiuntiva non è strettamente necessaria.

Fork di SmartATR

Torniamo ora al repository che avevamo inizialmente previsto di utilizzare. Ripeteremo gli stessi passi - creando un fork tramite l'interfaccia web di MQL5 Algo Forge e clonando localmente - il repository SmartATR.

Si inizia cercando il repository originale nella sezione Esplora inserendo il suo nome:

Poiché il repository ha già diversi fork creati da altri utenti, i risultati della ricerca mostrano anche questi fork. Per trovare il vero originale, scorriamo i risultati più in basso e apriamo la pagina di steverosenstock/SmartATR.

A questo punto facciamo clic sul pulsante Fork (Deriva):

Dopo aver fatto clic, si viene reindirizzati alla pagina delle impostazioni di creazione del fork. Qui si può rinominare il repository derivato (come apparirà nell'elenco dei repository), specificare quali rami dell'originale devono essere inclusi e modificare la descrizione del repository, se lo si desidera:

Per impostazione predefinita, il fork viene creato come copia esatta del repository originale. Per noi funziona perfettamente, quindi facciamo semplicemente clic su "Fork repository".

Il fork è stato creato con successo:

Quindi, cloniamo questo repository sul nostro computer locale. Prima di fare ciò, cancelliamo la cartella originale di SmartATR precedentemente clonata dal computer locale. Se MetaEditor era già aperto, è necessario aggiornare l'elenco delle cartelle selezionando Aggiorna dal menu contestuale di Progetti Condivisi. Successivamente, viene visualizzata la cartella SmartATR e dal menu contestuale si seleziona 'Git Clone' (Crea una Copia di Git): 

Il progetto SmartATR è stato clonato con successo:

Ora siamo pronti per iniziare ad apportare modifiche.

Apportare Modifiche

Poiché il nostro obiettivo è introdurre correzioni che risolvano o almeno neutralizzino un errore specifico, iniziamo creando un nuovo ramo il cui nome rifletta chiaramente questo scopo; per esempio, fixes/news-impact:

Passiamo quindi a questo ramo nel menu contestuale del progetto selezionando "Rami Git → fixes-news-impact".

Notare che, sebbene in origine sia stata inserita uno slash ("/") nel nome del ramo, il ramo è stato creato con questo carattere, sostituito automaticamente da un trattino ("-"). Si tratta di una limitazione imposta da MetaEditor, che consente solo lettere latine e trattini nei nomi dei rami. Tecnicamente, Git stesso consente gli slash e attraverso l'interfaccia web possiamo creare liberamente rami che li contengono. 

Verifichiamo l'importanza di questa restrizione. Creeremo un altro ramo direttamente nell'interfaccia web di MQL5 Algo Forge, questa volta includendo esplicitamente uno slash nel suo nome: fixes/cast-warning. Dalla pagina Rami, selezioniamo Nuovo ramo, usando il ramo main come base:

Il ramo è stato creato con successo:

Tuttavia, quando si tenta di eseguire un Pull in MetaEditor, viene visualizzato un messaggio di errore:

Tuttavia, il nuovo ramo con lo slash nel nome appare nell'elenco dei rami all'interno di MetaEditor e il passaggio ad esso funziona senza ulteriori problemi:

Dopo aver preso nota di questa particolarità, si torna al ramo fixes-news-impact e si introduce la correzione temporanea che elimina la causa dell'errore di compilazione:

Una volta che l'indicatore è stato compilato senza errori, si può eseguire il commit delle modifiche attraverso l'opzione del menu contestuale "Git Commit" (Salva le Modifiche in Git): 

Nella finestra di dialogo dei commit, si controlla l'elenco dei file modificati. Il controllo è semplice in questo caso, poiché abbiamo modificato solo un file. Si raccomanda vivamente di aggiungere un commento descrittivo che spieghi la natura della correzione. Dopo aver confermato che tutto è corretto, si preme OK.

Le nostre modifiche sono ora compiute e inviate al nostro fork del repository SmartATR in MQL5 Algo Forge. In questa fase, la versione corretta dell'indicatore può già essere utilizzata localmente, con una copia sicura conservata nel repository. Opzionalmente, possiamo inviare una Pull Request all'autore del progetto originale premendo "New pull request" nell'interfaccia web del repository:

Tuttavia, è troppo presto, poiché la nostra modifica si limita a disabilitare una parte della funzionalità piuttosto che a migliorare il codice. Per ora, non creiamo una richiesta di pull.

L'indicatore SmartATR è pronto per essere integrato nel nostro progetto Simple Candles.

Integrazione dell'Indicatore

Seguendo le best practice, creiamo un nuovo ramo nel repository del progetto Simple Candles - article-19436-forge3 - basato sul ramo develop. Per variare il nostro approccio, creiamo questo ramo utilizzando l'interfaccia web di MQL5 Algo Forge.

Per far apparire il ramo localmente, eseguiamo 'Git Pull' (Ottieni le Modifiche dall’Archivio Git) in MetaEditor e poi passiamo al nuovo ramo article-19436-forge3.

Poiché la nostra intenzione è quella di applicare l'indicatore all'interno della strategia di trading, lo aggiungiamo direttamente all'implementazione della classe della strategia in SimpleCandlesStrategy.mqh. In particolare, si introduce un campo di classe per memorizzare l'handle dell'indicatore:

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

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

Successivamente, si chiama iCustom() nel costruttore della classe, passando il simbolo richiesto, il timeframe, il percorso del file dell'indicatore e i suoi parametri:

//+------------------------------------------------------------------+
//| 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
                     );

      // ...
   }
}

Notare il percorso specificato per l'indicatore. Inizia con Progetti Condivisi, poi il nome della cartella del progetto SmartATR, seguito dal nome del file dell’indicatore SmartATR.ex5. L'inclusione dell'estensione .ex5 è facoltativa, ma mantenerlo aiuta ad evitare confusione.

C'è una sfumatura importante da tenere in considerazione quando si lavora nella cartella Progetti Condivisi. Questo si riferisce sia al proprio progetto che a quello derivato (fork). Tutti gli eseguibili compilati non vengono inseriti direttamente nella cartella del repository. Questo perché la cartella Progetti Condivisi si trova nella cartella principale dei dati del terminale: MQL5/Progetti Condivisi. Da un lato, ciò è positivo poiché il sistema di controllo della versione non cercherà di suggerire l'indicizzazione dei file eseguibili. D'altra parte, all'inizio può essere un po' confuso: Dove si trovano i file compilati degli Expert Advisor e degli indicatori?

Vengono effettivamente creati nelle rispettive cartelle standard, come MQL5/Experts per gli EA o MQL5/Indicators per gli indicatori. All'interno di questi, viene creata automaticamente una sottodirectory Progetti Condivisi. Quindi, i file compilati vengono creati proprio in queste sottocartelle. Ciò significa che la compilazione di un file da MQL5/Shared Projects/SmartATR.mq5 produrrà l'eseguibile in MQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5.

Di conseguenza, la chiamata iCustom() deve fare riferimento al percorso dell'indicatore relativo a MQL5/Indicators.

Infine, compiliamo il file del consulente SimpleCandles.mq5 ed eseguiamolo nel tester di strategie. I log mostrano quanto segue:

In questo modo, l'indicatore SmartATR è stato caricato e inizializzato con successo ed è pronto per l'uso. A questo punto, stiamo solo dimostrando la sua integrazione. Potremmo aggiungere l'uso effettivo all'interno della logica della strategia in un secondo momento. Eseguiamo il commit di queste modifiche e le inviamo al repository MQL5 Algo Forge.

Conclusioni

Questo articolo dimostra come l'adozione di MQL5 Algo Forge consenta un flusso di lavoro fondamentalmente più flessibile per gli sviluppatori. In precedenza abbiamo esaminato solo repository autonomi, ma qui abbiamo integrato con successo nel nostro progetto una libreria esterna proveniente da un repository di terze parti.

Il momento chiave è stato il corretto flusso di lavoro basato sul fork, ovvero la creazione di una copia personale di un repository esterno che consente di modificarlo completamente rimanendo sincronizzati con il progetto a monte. Il successo dell'integrazione di SmartATR in Simple Candles supporta questo approccio: dall'individuazione e dal fork del repository, alla modifica e all'applicazione del suo codice in una strategia di trading live.

È importante notare che questo processo è stato realizzato interamente con le attuali funzionalità di MetaEditor, senza attendere aggiornamenti futuri. Le limitazioni di MetaEditor (come la mancanza di accesso diretto ai repository di terze parti e la denominazione limitata dei rami) sono facilmente superabili integrandolo con l'interfaccia web di MQL5 Algo Forge e se necessario, con i comandi standard della console Git. In breve, il sistema è già utilizzabile nella pratica e le restanti carenze dell'interfaccia sono inconvenienti piuttosto che blocchi.

Tuttavia, non fermiamoci qui. Continueremo a usare i repository per separare i progetti e condividere le esperienze acquisite lungo il percorso.

Grazie per l'attenzione! A presto!