Migrando para o MQL5 Algo Forge (Parte 3): Uso de repositórios de terceiros em seu próprio projeto

Introdução

Na segunda parte da descrição de nossa transição para MQL5 Algo Forge, concentramos nossos esforços na resolução de uma das tarefas mais importantes: o trabalho com múltiplos repositórios. Tomando como exemplo a combinação do projeto de biblioteca Adwizard e do projeto de Expert Advisor Simple Candles, enfrentamos e solucionamos com sucesso os problemas surgidos, a maioria dos quais relacionados a caminhos de inclusão de arquivos e à fusão de branches. Buscamos realizar todo o processo, desde a criação de uma branch separada para correções até sua fusão por meio de um Pull Request, utilizando as ferramentas do MetaEditor. No entanto, quando sua funcionalidade não era suficiente, recorremos à interface web do repositório MQL5 Algo Forge, a um cliente Git externo no Visual Studio Code ou a comandos de console Git. Isso mostrou claramente que, mesmo no desenvolvimento individual, é possível aplicar boas práticas do Git para manter a organização e o histórico de mudanças de um projeto.

No entanto, esse foi apenas um dos dois lados do uso do repositório: um ecossistema "fechado", no qual o desenvolvedor é dono de todos os repositórios utilizados. O próximo passo lógico — e um dos motivos para a migração para o Git — é a possibilidade de usar plenamente os repositórios públicos de outros membros da comunidade. É justamente aí que se revela o verdadeiro potencial do desenvolvimento distribuído: a capacidade de conectar e atualizar facilmente código de terceiros, participar de sua melhoria e construir projetos complexos a partir de componentes prontos e bem testados. 

Neste artigo, finalmente chegamos a uma tarefa promissora, mas também mais complexa: como, na prática, integrar e utilizar em seu projeto bibliotecas de repositórios alheios no MQL5 Algo Forge. E não "um dia no futuro", mas agora, sem esperar pelo desenvolvimento posterior das ferramentas de trabalho com repositórios no MetaEditor. 

Traçando o caminho

Neste artigo, daremos continuidade ao trabalho em nosso repositório de projeto Simple Candles, que servirá como um excelente campo de testes para experimentos. A estratégia de negociação existente já implementou um cálculo próprio de volatilidade, funcionalmente semelhante ao indicador padrão Average True Range (ATR). No entanto, em vez de nos contentarmos com essa solução, veremos como aprimorar o código utilizando implementações especializadas prontas da comunidade.

Para isso, recorreremos ao repositório público SmartATR, partindo do pressuposto de que ele contém uma versão mais avançada e otimizada do indicador. Nosso objetivo prático de longo prazo é modificar o Expert Advisor para oferecer a possibilidade de escolher entre continuar usando o cálculo interno ou alternar para o algoritmo da biblioteca externa SmartATR. No entanto, neste artigo não nos concentraremos em criar um EA funcional, mas sim em examinar as questões relacionadas à interação com repositórios de código.

Para alcançar esse objetivo, precisaremos seguir alguns passos. Primeiro, é preciso obter o código da biblioteca SmartATR no computador local e incorporá-lo ao nosso projeto. Veremos como adicionar um repositório de terceiros ao ambiente de trabalho, de modo que ele possa ser facilmente atualizado sempre que novas versões forem lançadas. Em seguida, será necessário aplicar modificações tanto no código do projeto Simple Candles quanto no próprio código da biblioteca SmartATR. Se possível, evitaríamos alterações no código externo, mas, como tais circunstâncias surgiram, aproveitaremos este caso para treinar o processo de realizar alterações em repositórios alheios. Por fim, verificaremos a possibilidade de conectar e compilar o código do indicador da biblioteca dentro do nosso projeto.

Essa abordagem nos permitirá praticar detalhadamente todo o processo de integração de código de terceiros. A experiência adquirida será universal: depois de adicionar com sucesso uma biblioteca, poderemos, pelo mesmo esquema, incorporar em nossos projetos quaisquer outros repositórios públicos do MQL5 Algo Forge.

Obtendo código de terceiros

Aqui, aparentemente, não deveria haver dificuldades. Qualquer repositório Git pode ser clonado para o computador local com o comando de console:

git clone

Mas estabelecemos como regra começar sempre tentando pelo MetaEditor, depois recorrer à interface web do MQL5 Algo Forge, e só em último caso, quando não houver solução ali, utilizar ferramentas externas (como Visual Studio Code) ou comandos de console Git.

A primeira questão, portanto, é: como visualizar um repositório de terceiros no MetaEditor para selecioná-lo e cloná-lo? A resposta parcial pode ser encontrada na página de ajuda, mas dificilmente alguém pensaria em procurar por ela diretamente. Infelizmente, nós mesmos só descobrimos essa página mais tarde. Antes disso, nos deparamos com a situação de vermos, dentro da pasta Shared Projects, exclusivamente nossos próprios repositórios. Então, tentamos explorar o menu de contexto dessa pasta no Navegador do MetaEditor. 

A opção "New Project" não resolve, pois cria um novo repositório nosso. O uso do botão "Refresh" também não adiciona repositórios de terceiros. A opção "Show All Files", por sua vez, ainda apresenta um comportamento estranho: após sua ativação, aparecem duplicatas dos nomes de nossos próprios repositórios que ainda não foram clonados neste computador. Felizmente, esses duplicados desaparecem após clicar novamente em "Refresh". A última esperança era a opção "Show All Public Projects", mas ativá-la e desativá-la também não trouxe nenhuma mudança.

Portanto, infelizmente, no momento não conseguimos contar apenas com os recursos do MetaEditor para obter um clone de repositório de terceiros. Vamos então analisar dois caminhos que nos permitem alcançar o resultado desejado.

Primeiro caminho: clonagem direta

Para começar, tentemos um pequeno experimento. Se criarmos uma pasta vazia com um nome arbitrário (por exemplo, TestRepo) dentro da pasta Shared Projects, ela aparecerá no MetaEditor. Inclusive, é possível executar nela o comando "Clone" a partir do menu de contexto, ou seja, a opção fica disponível. No entanto, pelos logs, fica claro que o sistema tenta clonar do Forge o nosso próprio repositório chamado TestRepo, que obviamente não existe:

Ou seja, esse método não serve para clonar repositórios de terceiros. Vamos então tentar outra abordagem: clonar diretamente o repositório SmartATR na pasta Shared Projects, usando o comando de console `git clone ...`, e ver o que acontece.

Após a clonagem, uma nova pasta chamada SmartATR surge dentro de Shared Projects e passa a ser exibida no Navegador do MetaEditor. Mais do que isso, não apenas conseguimos visualizar o repositório na lista, como também trabalhar com ele como com qualquer outro, atualizando-o via Pull e consultando seu histórico de mudanças via Log, tudo a partir do MetaEditor:

Portanto, o que ainda falta na interface do MetaEditor é uma opção de menu de contexto semelhante a "Clone from...", que permita informar diretamente o endereço de um repositório de interesse dentro do Forge ou abrir uma janela de busca para selecionar entre todos os repositórios públicos disponíveis na seção Explore do MQL5 Algo Forge. Outra possibilidade seria exibir, na lista de Shared Projects, não apenas os repositórios próprios, mas também os repositórios de terceiros adicionados como favoritos na interface web (Starred Repositories), com a opção de mostrar ou ocultar esses repositórios. Mas não vamos nos antecipar, veremos no futuro quais mudanças serão realmente implementadas no MetaEditor.

Voltando ao repositório SmartATR já clonado, podemos dizer que a meta inicial foi alcançada: temos em nosso computador o código-fonte desse projeto e podemos utilizá-lo em nossos próprios trabalhos. Porém, há um detalhe... Avançaremos apenas se o código do projeto SmartATR não exigir nenhuma modificação, ou seja, se pudermos usá-lo "pronto para uso", limitando-nos a atualizações periódicas para versões mais recentes publicadas. Vamos verificar se isso é possível.

Verificação de funcionamento

Dentro do projeto SmartATR recebemos um arquivo com o código-fonte de um indicador para o MetaTrader 5 que, segundo a descrição do projeto, calcula o Average True Range (ATR) de uma forma mais sofisticada do que o indicador ATR padrão que vem junto com a instalação do MetaTrader 5. Vamos tentar compilá-lo... e nos deparamos com um erro. 

Portanto, independentemente da gravidade desse erro, o essencial é que não conseguiremos escapar de modificar o código de um projeto de terceiros. Agora, precisamos decidir se aplicaremos essas alterações apenas para uso próprio ou se as compartilharemos, contribuindo diretamente para o repositório original. Afinal, outros desenvolvedores também enfrentarão o mesmo problema ao tentar utilizá-lo. Por isso, a segunda opção é claramente mais recomendável, pois está muito mais alinhada com a filosofia do software livre e do desenvolvimento colaborativo.

Mas, antes de pensar em publicar as correções, é preciso resolver o problema. Só então haverá algo a ser compartilhado. Se, por ora, optarmos por aplicar os ajustes apenas para nós mesmos, basta criar uma branch local destinada a essas alterações. 

Vamos testar isso. O repositório original possui apenas a branch main, então criaremos uma nova branch chamada develop através do menu de contexto da pasta do projeto no MetaEditor. A branch foi criada e passou a constar na lista de branches exibida pelo editor. Após executar Push, os logs confirmam que o envio foi realizado com sucesso. Seria natural esperar que a nova branch tivesse aparecido também no repositório original, mas uma verificação no web interface do MQL5 Algo Forge mostrou que isso não aconteceu.

Em seguida, tentamos aplicar mudanças e realizar a commit dessas alterações pelo MetaEditor. Inserimos um comentário antes de cada linha onde os erros surgiam, indicando a necessidade de correção, e registramos o commit. Nos logs do MetaEditor foi exibido que tanto a fixação (commit) quanto o envio (push) foram concluídos com êxito:

No entanto, uma nova verificação no web interface do repositório MQL5 Algo Forge mostrou que, mais uma vez, nada havia mudado no repositório original. Isso é, no mínimo, estranho. Vamos tentar entender melhor a situação utilizando o VS Code. Ao abrir a pasta com o nosso clone do projeto SmartATR, observamos o seguinte:

Como é possível ver, o último commit realmente existe, mas aparece a sugestão para publicar a branch develop. Isso significa que essa branch ainda não foi criada no repositório remoto, e, portanto, o nosso último commit também não foi enviado para lá. Ao tentar publicá-la, recebemos o seguinte erro:

A causa fica clara ao analisar os logs:

Nosso usuário não tem permissão de escrita no repositório original. Isso faz todo sentido: se qualquer pessoa pudesse enviar alterações diretamente, o projeto rapidamente se tornaria caótico, cheio de mudanças não controladas. Dessa forma, conseguimos aplicar modificações apenas em nossa cópia local, que... não pode ser sincronizada com nenhum outro lugar e acaba existindo apenas nesse clone específico no computador local. Esse cenário não é aceitável, pois os repositórios externos, além de possibilitarem a colaboração, cumprem a essencial função de garantir o armazenamento seguro e redundante do código do projeto. Abrir mão disso seria um grande risco.

Outro ponto importante é que, trabalhando somente dentro do MetaEditor, não foi possível perceber que algo estava errado. Se olharmos apenas para os logs exibidos por ele, tudo parece normal: não há mensagens de erro e todos os commits parecem ter sido feitos com sucesso... mas, na prática, os commits são feitos para um repositório que não existe. Esperamos que isso seja corrigido nas próximas versões.

Caminho dois: clonando um fork

Vamos então tentar uma outra abordagem. Aqui também precisaremos sair um pouco das funcionalidades atuais do MetaEditor, mas será suficiente recorrer apenas ao web interface do repositório MQL5 Algo Forge. Para quem tem dificuldades em lidar com comandos de terminal ao trabalhar com Git, esse pode ser um bom caminho intermediário. Afinal, no web interface é possível criar um fork do repositório original que nos interessa. 

Fork é um conceito fundamental em sistemas de controle de versão e em plataformas de desenvolvimento colaborativo, como o MQL5 Algo Forge. Ele representa a criação de uma cópia completa e independente de um repositório original dentro da própria plataforma.

Ao criar um fork de um repositório de terceiros, a plataforma gera uma cópia exata dentro do espaço da sua conta. Essa cópia herda todo o histórico de alterações, branches e arquivos do projeto original no momento em que o fork é criado. A partir daí, o repositório se torna independente e o novo proprietário pode modificá-lo livremente, sem que isso tenha qualquer impacto sobre o repositório de origem.

Dessa forma, o fork permite que qualquer pessoa utilize um projeto existente como base e o desenvolva de acordo com sua própria visão, criando, na prática, um novo ramo do projeto. Esse mecanismo é a base para a criação de projetos derivados e de implementações alternativas dentro da filosofia de software aberto.

O fork é também a principal ferramenta para propor mudanças em projetos originais nos quais o usuário não tem permissão de escrita. O fluxo de trabalho (workflow) padrão segue a seguinte lógica: cria-se um fork, nele são preparados e testados os ajustes necessários e, em seguida, o autor do repositório original é notificado das melhorias sugeridas por meio de um Pull Request (solicitação de integração de mudanças), sobre o qual já falamos na segunda parte. Esse processo é o alicerce do modelo descentralizado de desenvolvimento colaborativo.

Apesar de ser independente, o fork mantém tecnicamente uma ligação com o repositório de origem. Isso torna simples acompanhar as evoluções do projeto original e sincronizar o fork, incorporando novas alterações vindas dele.

É importante distinguir fork de simples clonagem (clone). Clonar é apenas obter uma cópia local de um repositório em um computador específico. Já o fork é a duplicação completa do repositório dentro da própria plataforma, criando um novo projeto remoto sob a conta de outro usuário.

Assim, ao fazermos o fork de um repositório de terceiros, passamos a ter um repositório próprio. Isso significa que ele aparece na lista de repositórios exibida dentro da pasta Shared Projects e fica pronto para ser clonado diretamente no MetaEditor.

Testando o funcionamento com um fork

Com a colaboração gentil de Fernando Carreiro, verificamos esse mecanismo na prática. Para isso, criamos um fork do repositório dele FMIC, e, ao mesmo tempo, adicionamos o repositório original na nossa lista de acompanhados (Watch) e favoritos (Star) dentro do web interface da plataforma.

Logo em seguida, ele apareceu na lista de repositórios exibidos em Shared Projects no MetaEditor:

Assim, conseguimos clonar para o computador local o nosso fork recém-criado do repositório original FMIC.

Depois, pedimos que fosse feito um commit de alguma alteração para avaliarmos como seríamos notificados dessas mudanças e como poderíamos atualizar o fork. Fernando adicionou, como teste, um arquivo README.md contendo a descrição da publicação sobre Heikin Ashi, e fez o commit no repositório.

Depois disso, realmente vimos no web interface do repositório uma notificação sobre as alterações feitas:

No entanto, até esse momento, tais notificações não tiveram nenhum efeito direto nem sobre o fork do repositório na nossa conta, nem sobre o clone desse fork no computador local. Vamos então tentar trazer as modificações feitas por Fernando para dentro dos nossos repositórios. Primeiro, confirmamos que o nosso clone local do fork realmente não contém essas últimas alterações:

Como é possível ver, o último commit no histórico local está datado de 27 de agosto de 2025, enquanto as últimas mudanças foram realizadas depois dessa data.

Se acessarmos agora o web interface do nosso fork, veremos uma mensagem informando que a nossa branch main está três commits atrás da branch correspondente no repositório original:

Nesse mesmo local, aparece o botão "Sync", cuja função é justamente sincronizar as alterações entre a branch original e a nossa branch main. Clicamos nesse botão, e em seguida abrimos o MetaEditor para executar o comando Pull no clone do nosso fork. Ao consultar o histórico de commits, já é possível observar os três novos commits datados de 05 de setembro de 2025, que antes não estavam disponíveis:

Ou seja, todos os commits feitos no repositório original foram corretamente transferidos, primeiro para o repositório fork no MQL5 Algo Forge, e depois para o clone desse repositório no computador local.

Para quem quiser se aprofundar no funcionamento desse mecanismo, recomendamos a leitura dos seguintes trechos da documentação do GitHub: 

• Criação de fork
• Configuração de upstream
• Sincronização

É verdade que esse material não foi escrito especificamente para o MQL5 Algo Forge, mas a maior parte da lógica no web interface funciona de forma quase idêntica. Já os comandos de console, por sua vez, não dependem da plataforma, desde que seja utilizada a tecnologia Git.

Por exemplo, seguindo as instruções da seção configuração de upstream, poderíamos configurar a sincronização automática entre o clone do fork e o repositório original sempre que usássemos os comandos Pull/Push:

No entanto, ao trabalhar apenas pelo MetaEditor e pelo web interface do MQL5 Algo Forge, essa etapa adicional não é necessária.

Fork do SmartATR

Voltemos agora ao repositório que inicialmente planejávamos integrar. Vamos repetir os mesmos passos já realizados: criar um fork no web interface do MQL5 Algo Forge e, em seguida, clonar esse fork no computador local para o repositório SmartATR.

Para isso, basta localizar o repositório original desejado na aba Explore, digitando o nome SmartATR:

Como o repositório em questão já possui vários forks criados por outros usuários, na lista de resultados da busca vemos também essas versões derivadas. Para garantir que o fork seja criado a partir do repositório original, é necessário rolar a lista até encontrar o projeto steverosenstock/SmartATR e acessar diretamente sua página.

Ali, clicamos no botão de criação do fork:

Após essa ação, somos direcionados para a página de propriedades do fork que está sendo criado. Nessa etapa, é possível alterar o nome do repositório (que definirá como ele aparecerá na lista de nossos projetos), escolher quais branches do repositório original desejamos transferir para nosso fork e editar a descrição antes da criação:

Por padrão, ao criar um fork, é feita uma cópia exata do repositório original. Isso nos atende perfeitamente, portanto basta clicar em "Fork repository".

O fork foi criado com sucesso:

Agora podemos criar o clone desse repositório no computador local. Antes disso, removemos a pasta previamente criada com o repositório original. Se o MetaEditor já estava aberto, para que a nova pasta SmartATR apareça na lista de subpastas, é necessário executar o comando "Refresh" no menu de contexto de Shared Projects dentro do Navigator. Após isso, no menu de contexto da pasta SmartATR, escolhemos a opção "Git Clone": 

O projeto SmartATR foi clonado com sucesso:

Já podemos começar a trabalhar nas modificações.

Fazendo alterações

Como o objetivo é realizar ajustes que corrijam ou pelo menos neutralizem o erro identificado, criamos uma nova branch cujo nome reflete essa finalidade (fixes/news-impact):

Em seguida, alternamos para ela no menu de contexto do projeto, escolhendo "Git Branches → fixes-news-impact":

É importante notar que, apesar de termos usado o caractere "/" no nome da branch ao criá-la, no repositório local ela foi automaticamente renomeada para utilizar "-". Embora não haja uma restrição explícita no Git quanto ao uso de barra nos nomes de branches, o MetaEditor impõe essa limitação: ao criar uma branch por meio dele, só são aceitos caracteres alfabéticos latinos e o hífen. 

Para verificar até que ponto essa limitação é relevante, criamos outra branch diretamente no web interface do MQL5 Algo Forge, desta vez utilizando a barra no nome, por exemplo, fixes/cast-warning. Para isso, acessamos a página Branches e clicamos no botão de criação de uma nova branch a partir da existente main:

A branch foi criada com sucesso:

No entanto, ao executar o comando Pull no MetaEditor, recebemos uma mensagem de erro:

Mesmo assim, a nova branch com barra no nome aparece listada no MetaEditor, e alternar para ela não gera mensagens adicionais de erro:

Tendo observado essa particularidade, voltamos para a branch fixes-news-impact e fazemos as alterações necessárias, removendo temporariamente a causa do erro:

Após essa modificação, o arquivo do indicador compila sem problemas, e podemos registrar nossas alterações através da opção de menu de contexto "Git Commit": 

Na janela exibida, conferimos a lista de arquivos que sofreram alterações e que desejamos incluir no commit. Quando se trata de apenas um arquivo, essa verificação é bastante simples. Também é altamente recomendável adicionar um comentário descrevendo de forma clara quais alterações foram feitas nesse commit. Uma vez verificado que tudo está correto, clicamos em OK.

Feito isso, as alterações são enviadas para o nosso repositório remoto no MQL5 Algo Forge, que corresponde ao fork do repositório original do projeto SmartATR. Agora já podemos utilizar a versão corrigida do indicador no computador local, com a garantia de que sua cópia de segurança também está salva no nosso repositório remoto. Em seguida, se quisermos, podemos propor que essas correções sejam incorporadas ao projeto original por meio de um Pull Request, clicando em "New pull request" na página Branches do web interface.

No entanto, ainda não é o momento de fazer isso, pois até aqui não realizamos nenhuma melhoria significativa no código do projeto, apenas desabilitamos parte da funcionalidade que apresentava erros. Portanto, não criaremos um Pull Request agora.

Tudo está pronto para começarmos a usar o indicador SmartATR dentro do nosso projeto Simple Candles.

Conectando o indicador

Seguindo as boas práticas já adotadas, criaremos uma nova branch chamada article-19436-forge3 no repositório do projeto, derivada da branch develop. Para variar, desta vez faremos isso diretamente pelo web interface do MQL5 Algo Forge, conforme já demonstrado anteriormente.

Para que essa nova branch apareça no clone local do repositório, executamos o comando "Git Pull" a partir do menu de contexto do projeto no MetaEditor e, em seguida, alternamos para a branch recém-criada article-19436-forge3.

Como vamos aplicar esse indicador dentro da estratégia de negociação, sua integração será feita no arquivo da classe correspondente, SimpleCandlesStrategy.mqh. Nele, adicionaremos ao conjunto de campos da classe uma variável destinada a armazenar o handle do indicador:

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

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

Em seguida, no construtor da classe, chamaremos a função iCustom(), passando como parâmetros o símbolo, o período gráfico, o caminho até o arquivo do indicador e a lista de parâmetros exigidos pelo próprio indicador:

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

      // ...
   }
}

Perceba como indicamos o caminho para o arquivo do indicador. Ele começa com o nome da pasta Shared Projects, depois vem a pasta do repositório do projeto SmartATR e, por fim, o próprio nome do arquivo do indicador SmartATR.ex5. A extensão .ex5 poderia ser omitida, mas a deixamos de propósito para que ficasse claro onde termina o nome da pasta e onde começa o nome do indicador em si.

Há ainda um detalhe importante a considerar ao trabalhar com projetos na pasta Shared Projects. Isso vale tanto para projetos próprios quanto para projetos de terceiros. O ponto é que, durante a compilação, os arquivos executáveis não são gerados dentro da pasta do repositório, mas em outro local! Isso acontece porque a pasta Shared Projects fica na raiz da pasta de dados do terminal, ou seja, em MQL5/Shared Projects. De um lado, isso é positivo, pois o sistema de controle de versões não vai tentar incluir arquivos compilados no índice. Por outro lado, no começo pode ser um pouco confuso: afinal, onde procurar os arquivos compilados de experts e indicadores?

Na prática, nas pastas que correspondem aos diferentes tipos de programas (MQL5/Experts para EAs, MQL5/Indicators para indicadores etc.), durante a compilação são criadas automaticamente subpastas Shared Projects com as respectivas pastas dos projetos. É justamente nelas que os arquivos compilados vão parar. Ou seja, se compilarmos o arquivo fonte localizado em MQL5/Shared Projects/SmartATR.mq5, o executável resultante do indicador deverá ser procurado em MQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5.

Portanto, ao chamar a função iCustom(), precisamos especificar o caminho do indicador em relação à pasta MQL5/Indicators.

Feito isso, compilamos o arquivo do expert SimpleCandles.mq5, no qual já foram instanciadas estratégias de negociação que utilizam o indicador integrado, e o executamos no testador de estratégias para verificação. Nos logs aparecem as seguintes mensagens:

Ou seja, o código do indicador foi carregado com sucesso, inicializado corretamente e já pode ser usado pelo advisor. Por enquanto, ele não desempenha nenhuma função prática, já que o objetivo aqui era apenas demonstrar a viabilidade de integrá-lo. A aplicação real virá mais adiante. Registramos nossas alterações com um commit e enviamos as modificações para o repositório no MQL5 Algo Forge.

Considerações finais

Mostramos que a migração para o MQL5 Algo Forge abre aos desenvolvedores novas possibilidades de organização do fluxo de trabalho. Se antes havíamos analisado apenas o uso de repositórios próprios em um modo "fechado", agora conseguimos integrar com sucesso em nosso projeto uma biblioteca externa proveniente de um repositório de terceiros.

O ponto-chave foi utilizar o fluxo de trabalho correto por meio da criação de um fork, que é uma cópia pessoal de um repositório de terceiros e permite modificar o código livremente, mantendo a sincronização com o original. A implementação prática da integração da biblioteca SmartATR ao projeto Simple Candles confirmou a viabilidade de todo o processo, desde a busca pelo repositório e a criação do fork até o uso direto do código dentro de um expert advisor.

A integração foi realizada utilizando apenas os recursos atuais do MetaEditor, sem aguardar futuras atualizações. As limitações existentes no momento, como a ausência de um método direto para trabalhar com repositórios de terceiros e peculiaridades no gerenciamento de branches, podem ser compensadas pelo uso da interface da web do MQL5 Algo Forge e de comandos de console do Git. Dessa forma, o sistema já está pronto para uso e os pequenos inconvenientes de interface não chegam a ser um obstáculo para o trabalho pleno, ainda que causem certa dose de desconforto.

Mas não vamos parar por aqui. Continuaremos utilizando os repositórios para separar o código de diferentes projetos e compartilhando a experiência adquirida ao longo desse processo.

Obrigado pela atenção e até a próxima!