Cambiando a MQL5 Algo Forge (Parte 3): Uso de repositorios de terceros en su propio proyecto

Introducción

En la segunda parte de la descripción de nuestra migración a MQL5 Algo Forge, nos centramos en resolver uno de los problemas más importantes: el trabajo con múltiples repositorios. Utilizando el ejemplo de enlace del proyecto de biblioteca Adwizard y el proyecto de asesor experto Simple Candles, encontramos y resolvimos con éxito los problemas encontrados, en su mayoría relacionados con las rutas de inclusión de archivos y la fusión de ramas. Tratamos de hacer todo el proceso (desde la creación de una rama separada para las correcciones a la fusión a través de Pull Request) utilizando herramientas MetaEditor. Pero en los casos en que su funcionalidad era deficiente, cambiamos a la interfaz web del repositorio MQL5 Algo Forge, a un cliente Git de terceros en la interfaz de Visual Studio Code, o a los comandos de consola de Git. Esto demostró claramente cómo, incluso dentro del desarrollo personalizado, podemos aplicar las mejores prácticas de Git para mantener el orden y la historia de cambios de un proyecto.

Pero esta era solo una de las dos facetas del uso de repositorios: un ecosistema "cerrado" en el que el desarrollador es propietario de todos los repositorios utilizados. El siguiente paso lógico, que es en gran medida de lo que trataba el cambio a Git, es la capacidad de usar plenamente los repositorios públicos de otros miembros de la comunidad. Aquí es donde se abre el verdadero potencial del desarrollo distribuido: la posibilidad de conectar y actualizar fácilmente el código de terceros, participar en su mejora y construir proyectos complejos partiendo de componentes ya listos y depurados. 

En el presente artículo, finalmente abordaremos esta tarea prometedora pero también compleja: cómo conectar y utilizar en la práctica bibliotecas de repositorios de terceros del almacenamiento MQL5 Algo Forge en nuestro proyecto. Y no algún tiempo después, sino ahora mismo, sin esperar al futuro desarrollo de herramientas para trabajar con repositorios en el MetaEditor. 

Trazando el camino

En este artículo, continuaremos trabajando en el repositorio de nuestro proyecto Simple Candles, que nos servirá como un gran campo de pruebas para la experimentación. La estrategia comercial existente ya implementa un cálculo de volatilidad independiente, funcionalmente similar al Average True Range (ATR) estándar. Sin embargo, en lugar de conformarnos con nuestra propia solución, veremos cómo podemos mejorar el código aprovechando los desarrollos especializados ya listos de la comunidad.

Para ello, recurriremos al repositorio de acceso público SmartATR: suponemos que contiene una versión más avanzada y optimizada del indicador. Nuestro lejano objetivo práctico es modificar el asesor experto dándole la opción de seguir utilizando el cálculo interno, o cambiar a un algoritmo de la biblioteca externa SmartATR. Sin embargo, en el marco de este artículo, no nos centraremos en la creación de un asesor experto que funcione, sino que consideraremos principalmente cuestiones relacionadas con la interacción con repositorios de código.

Para conseguirlo, debemos hacer lo siguiente. En primer lugar, tenemos que obtener el código de la biblioteca SmartATR en una computadora local y organizar su conexión con nuestro proyecto. Así, veremos cómo podemos añadir el repositorio de otra persona a nuestro entorno de trabajo para poder actualizarlo fácilmente en el futuro cuando se publiquen nuevas versiones. Después de ello, deberemos hacer ediciones en el código del proyecto Simple Candles y, como resulta, en el código de la biblioteca SmartATR. En una situación más favorable, podríamos prescindir de esto último, pero ya que el caso predispone a ello, utilizaremos este ejemplo para elaborar el algoritmo para realizar ediciones en el repositorio de terceras personas. Al final, comprobaremos la posibilidad de conexión y compilación conjunta del código de indicador de la biblioteca como parte de nuestro proyecto.

Este enfoque nos permitirá elaborar con detalle todo el proceso de integración del código de terceros. La experiencia adquirida será universal: tras añadir con éxito una biblioteca, podremos utilizar el mismo esquema para incluir cualquier otro repositorio público de MQL5 Algo Forge en nuestros proyectos.

Obteniendo el código de terceros

Aquí no parece haber ningún problema. Cualquier repositorio Git puede clonarse en nuestra computadora local utilizando el comando de consola

git clone ...

Pero hemos acordado primero intentar arreglárnoslas con la interfaz MetaEditor, luego con la interfaz web MQL5 Algo Forge y solo después de que los resultados no se pueden lograr allí, utilizar herramientas de terceros (Visual Studio Code) y comandos de la consola Git.

Así que la primera pregunta es ¿cómo podemos ver el repositorio de otra persona en MetaEditor para seleccionarlo para la clonación? Parte de la respuesta podría encontrarse en la página de ayuda, pero pocas personas conocerán de inmediato este lugar y adivinarán que deben buscar allí. Por desgracia, encontramos esta página más tarde. Y antes de eso, nos encontramos con que ahora vemos exclusivamente nuestros propios repositorios como parte de la carpeta Shared Projects. Vamos a intentar estudiar el menú contextual de esta carpeta en el Navegador del MetaEditor. 

La opción "New Project" no es adecuada para nosotros, ya que creará un nuevo repositorio. El uso de "Refresh" tampoco añadirá repositorios de terceros. El elemento "Show All Files" sigue funcionando de forma extraña: tras hacer clic en él, aparecen en la lista nombres duplicados de nuestros repositorios que no están clonados en esta computadora. Pero tras pulsar "Refresh", afortunadamente desaparecen. La última esperanza era la opción "Show All Public Projects", pero activar y desactivar este modo tampoco cambió nada.

Así que, desgraciadamente, por el momento no podemos utilizar únicamente las herramientas del MetaEditor para conseguir nosotros mismos un clon del repositorio de otra persona. Vamos a analizar un par de formas de conseguir lo que queremos.

Primera vía: clonación directa

Para empezar, realizaremos este experimento. Si creamos una carpeta vacía con un nombre aleatorio (por ejemplo, TestRepo) en la carpeta Shared Projects, esta será visible en el MetaEditor. Incluso podemos ejecutar el comando "Clone" desde el menú contextual sobre ella, lo que significa que se puede hacer clic en este elemento. Pero si hacemos eso, entonces, a juzgar por los logs, estaremos intentando clonar desde el repositorio nuestro repositorio llamado TestRepo, que por supuesto no existe:

Bueno, este método no funcionará para clonar el repositorio de otra persona. Así que ahora intentaremos clonar el repositorio SmartATR seleccionado en la carpeta Shared Projects usando el comando de consola git clone... y veremos qué ocurre.

Después de la clonación, la nueva carpeta SmartATR apareció en la carpeta Shared Projects, que se muestra en el Navegador en el MetaEditor. Y no solo podemos ver este repositorio en la lista del Navegador, sino también trabajar con él como repositorio: actualizar (Pull) y ver la historia de cambios (Log) desde el MetaEditor:

Así, la interfaz del MetaEditor sigue careciendo de un elemento de menú contextual del tipo "Clone from...", tras cuya selección se solicitaría al almacenamiento la dirección del repositorio de interés, o una posibilidad de abrir un diálogo de búsqueda y selección entre todos los repositorios públicos del repositorio MQL5 Algo Forge (como en la interfaz web de la sección Explore). Otra posible opción sería añadir la visualización en la lista de Shared Projects no solo de repositorios propios, sino también de los repositorios de otras personas añadidos a favoritos en la interfaz web (Starred Repositories) con la posibilidad de activar o desactivar la visualización de dichos repositorios. Pero no vamos a adivinar aquí qué cambios se introducirán en la interfaz del MetaEditor en el futuro.

Volviendo al repositorio SmartATR ya clonado, hemos conseguido el objetivo. Tenemos el código fuente de este proyecto en nuestro computadora local, lo cual significa que podemos utilizarlo en nuestros proyectos. Sin embargo, hay un matiz a considerar... Solo podremos avanzar si el código del proyecto SmartATR no requiere ningún cambio, es decir, si podemos utilizarlo "out-of-the-box", realizando únicamente actualizaciones periódicas a versiones publicadas más recientes. A ver si es posible.

Comprobación de funcionamiento

Como parte del proyecto SmartATR, obtenemos un archivo con el código fuente del indicador para MetaTrader 5, que, según la descripción del proyecto, permite calcular el indicador Average True Range (ATR) de una forma más sofisticada que el indicador ATR estándar suministrado con MetaTrader 5. Intentamos compilarlo... y obtenemos un error. 

Así que ni siquiera importa la gravedad de este error, lo principal es que no podemos seguir sin cambiar el código del proyecto de otra persona. Aquí es donde debemos decidir si vamos a hacerlos solo para nosotros, o si queremos compartir los cambios que hemos hecho e introducirlos en el repositorio de otra persona. Al fin y al cabo, otros desarrolladores también se encontrarán con un error de este tipo al intentar usar el código de este proyecto. Así que la segunda opción es, obviamente, la preferible. Su espíritu es mucho más cercano a la filosofía del desarrollo de software de código abierto.

Pero antes, vamos a imaginar que decidimos posponer la publicación de las correcciones para el futuro. De hecho, en primer lugar, deberemos ser capaz de corregir los errores que han surgido, y solo entonces habrá un tema para la publicación. Así que si al principio nos centramos en hacer ediciones en el proyecto SmartATR solo para nosotros, podemos simplemente crear una rama local para los cambios. 

Vamos a intentarlo. Hay una única rama main en el repositorio fuente, así que crearemos una nueva rama llamada develop a través del menú contextual de la carpeta del proyecto en MetaEditor. La rama se crea y aparece en la lista de ramas que muestra el MetaEditor. Tras pulsar Push, el registro mostrará un mensaje que indicará que el envío se ha realizado correctamente. Uno esperaría que la nueva rama apareciera en el repositorio original, pero una comprobación en la interfaz web del repositorio MQL5 Algo Forge nos mostrará que no ha sido así.

Vamos a tratar de hacer cambios y confirmarlos (Commit) a través del MetaEditor. Asimismo, añadiremos un comentario sobre la necesidad de realizar una corrección antes de cada línea en la que se hayan producido errores y registrar dichos cambios. El registro del MetaEditor muestra que tanto el commit como el push se han realizado correctamente:

Sin embargo, una doble comprobación en la interfaz web del repositorio MQL5 Algo Forge muestra que, nuevamente, nada ha cambiado en el repositorio de origen. Eso es, como mínimo, un poco raro. Vamos a intentar averiguar qué ocurre, consultando para ello VS Code. Una vez abierta la carpeta con el clon de nuestro proyecto SmartATR, vemos lo siguiente:

Como podemos ver, la última confirmación existe, pero se nos pide que publiquemos la rama develop. Es decir, esta rama aún no está disponible en el repositorio anterior, lo que significa que nuestro último commit tampoco estará allí. Intentamos publicar una rama y obtenemos este error:

Podemos ver su causa en el registro:

Es decir, nuestro usuario no tiene permisos de escritura en el repositorio original. En general, esto resulta lógico, porque si se pudiera hacer, el proyecto podría convertirse simplemente en algo incomprensible debido a la edición incontrolada por parte de cualquier usuario. Así que resulta que solo podemos hacer ediciones en nuestra copia local, que.... no se puede sincronizar en ningún sitio y solo existirá en este único clon del repositorio en esta computadora local. Esto no debería permitirse, porque además de la posibilidad de colaboración, los almacenamientos externos ofrecen otra función importante: el guardado de una copia de seguridad del código del proyecto. Y no deberíamos rechazar una oportunidad como esta.

Por otra parte, también vale la pena señalar que ahora, trabajando solo en el MetaEditor, no podemos ver que algo vaya mal. Si nos fijamos solo en los registros, estos muestran que todo está bien, no hay errores, todas las ediciones se envían de forma segura ... a nuestro repositorio inexistente... Esperemos que esto se solucione en las próximas versiones.

Segunda vía: clonar una bifurcación (fork)

Intentemos ahora ir en la otra dirección. Aquí también tendremos que sobrepasar las capacidades actuales del MetaEditor, pero podemos limitarnos al uso adicional de la interfaz web del repositorio MQL5 Algo Forge. Para aquellos que tienen dificultades para usar la línea de comandos para trabajar con repositorios, esta será una opción de compromiso. Así, en la interfaz web del repositorio, podemos crear una bifurcación del repositorio original que nos interesa. 

La bifurcación es un concepto fundamental en los sistemas de control de versiones y plataformas de desarrollo colaborativo, incluyendo MQL5 Algo Forge, que se refiere al proceso de creación de una copia completa e independiente del repositorio original dentro de la plataforma.

Cuando un usuario crea un bifurcación de un repositorio de terceros, la plataforma crea una copia exacta del mismo en el espacio de la cuenta del usuario. Esta copia hereda toda la historia de cambios, las ramas y los archivos del proyecto original en el momento en que se creó la bifurcación, pero a partir de ese momento se convierte en un objeto autónomo que el nuevo propietario puede modificar libremente sin ningún impacto en el repositorio original.

Así, un bifurcación permite a cualquier usuario tomar un proyecto existente y desarrollarlo a su manera, creando esencialmente una nueva rama del proyecto. Esta es la base para crear proyectos derivados e implementaciones alternativas dentro del concepto de software de código abierto.

La bifurcación es la herramienta principal para realizar cambios en proyectos fuente que el usuario no tiene derecho a modificar. El flujo de trabajo estándar para ello es el siguiente: se crea un bifurcación, se preparan y prueban en él los cambios necesarios y, a continuación, se notifica al autor del repositorio original las mejoras propuestas a través del mecanismo Pull Request, del que ya hablamos en la parte 2. Esta es la base del modelo de desarrollo colaborativo descentralizado.

A pesar de ser independiente, la bifurcación conserva técnicamente un enlace al repositorio original. Esto facilita el seguimiento de los cambios en el proyecto original y sincroniza nuestra copia con ellos, fusionando las nuevas ediciones del repositorio original en nuestra bifurcación.

Es importante distinguir una bifurcación de un simple clon. La clonación es la operación de obtener una copia local de un repositorio en un computadora concreta, mientras que la bifurcación es una copia completa de todo el repositorio dentro de la plataforma, creando un nuevo proyecto remoto bajo un usuario diferente.

Así que si hacemos un bifurcación del repositorio de otra persona, tendremos un nuevo repositorio propio. Así, estará disponible en la lista de repositorios generada en la carpeta Shared Projects y listo para ser clonado desde el MetaEditor.

Comprobación del trabajo con la bifurcación

Gracias a la amable ayuda de Fernando Carreiro, comprobamos este mecanismo en acción. Para ello, creamos un bifurcación de su repositorio FMIC añadiendo al mismo tiempo el repositorio original en la interfaz web del repositorio a la lista Observar (Watch) y favoritos (Star).

Esta apareció en la lista de repositorios mostrados en Shared Projects en el MetaEditor:

Así que pudimos clonar nuestro recién creada bifurcación del repositorio original FMIC en una computadora local.

A continuación, pedimos que se confirmaran los cambios para ver cómo podíamos conocerlos de cara a una actualización de la bifurcación. Fernando añadió la descripción de la publicación de Heikin Ashi como prueba en forma de archivo README.md y la confirmó en el repositorio.

Después de eso, vimos una alerta en la interfaz web del repositorio sobre los cambios realizados:

Pero hasta ahora estas alertas no han tenido ningún efecto ni en la bifurcación del repositorio en nuestro almacenamiento ni en el clon de esa bifurcación en la computadora local. Vamos a intentar migrar los cambios de Fernando a nuestros repositorios. En primer lugar, comprobaremos que no haya cambios recientes en nuestro clon local:

Como podemos ver, el último commit en la historia de la computadora local tiene fecha de 27 de agosto de 2025, y los últimos cambios realizados se hicieron más tarde.

Si ahora vamos a la interfaz web de nuestra bifurcación, podemos ver un mensaje allí indicando que nuestra rama main se encuentra tres commits por detrás de esta rama en el repositorio original:

También podemos ver el botón "Sync", que, al pulsarlo, debería sincronizar las ediciones en la rama original y nuestra rama main. Hacemos clic en este botón, a continuación, entramos en el MetaEditor y ejecutamos el comando Pull para el clon de nuestra bifurcación. Entonces abrimos la historia de commits y vemos que hay tres nuevos commits desde el 05 de septiembre de 2025 que no estaban antes:

Es decir, todos los commits realizados en el repositorio original han sido trasladados de forma segura primero al repositorio de bifurcación en el repositorio MQL5 Algo Forge y luego al clon de este repositorio en la computadora local.

Para quienes deseen saber más sobre cómo utilizar este mecanismo, le recomendamos leer las siguientes secciones de ayuda de la documentación de GitHub: 

• Creando una bifurcación
• Configuración upstream
• Sincronización

Sí, no está escrito específicamente para MQL5 Algo Forge, pero muchas cosas en la interfaz web funcionan casi de la misma forma, y los comandos de la consola no están vinculados al tipo de almacenamiento utilizado en absoluto. Lo importante es que usen Git específicamente.

Por ejemplo, guiándonos por el material en la configuración upstream, podemos configurar la bifurcación del clon para que se sincronice con el repositorio original siempre que se ejecuten comandos Pull/Push:

Pero cuando trabajamos a través de MetaEditor y la interfaz web del repositorio MQL5 Algo Forge, este paso no es necesario.

Bifurcación SmartATR

Volvamos ahora al repositorio que pensábamos usar en un principio. Vamos a repetir los pasos ya realizados para crear un bifurcación en la interfaz web del repositorio MQL5 Algo Forge y clonarla en un computadora local para el repositorio SmatrATR.

Busque el repositorio original deseado especificando el nombre del repositorio deseado en la página Explore

Como el repositorio deseado ya tiene varias bifurcaciones creadas por otros usuarios, también las veremos en la lista de resultados de la búsqueda. Para crear una bifurcación específicamente a partir del repositorio original, deberemos desplazarnos hacia abajo en la lista de resultados y dirigirnos a la página específica del repositorio steverosenstock/SmartATR.

Allí haremos clic en el botón para crear una bifurcación:

Una vez pulsado, nos llevará a la página de propiedades de la bifurcación creada. Aquí podemos, por ejemplo, cambiar el nombre del repositorio de la bifurcación bajo el que existirá en la lista de nuestros repositorios, especificar qué ramas del repositorio original queremos transferir a nuestra bifurcación y editar la descripción de la bifurcación creada:

Por defecto, la creación de un bifurcación creará una copia exacta del repositorio original. Estamos bastante contentos con eso, así que simplemente haremos clic en el botón "Fork repository".

La bifurcación se ha creado correctamente:

Ahora vamos a crear un clon de este repositorio en el equipo local. Antes, eliminaremos la carpeta creada anteriormente con el repositorio original en la computadora local. Si el MetaEditor ya se ha iniciado anteriormente, para que la carpeta SmartATR aparezca en la lista de subcarpetas, deberemos ejecutar el comando "Refresh" del menú contextual de la carpeta Shared Projects en el Navegador. A continuación, seleccionaremos "Git Clone" en el menú contextual de la carpeta SmartATR : 

El proyecto SmartATR se ha clonado con éxito:

Podemos empezar el trabajo de corrección.

Introducimos las correcciones

Como queremos introducir correcciones que arreglen o al menos neutralicen un fallo concreto, crearemos una nueva rama con el nombre que refleje nuestro objetivo (fixes/news-impact):

Y alternaremos a esta en el menú contextual del proyecto seleccionando "Git Branches → fixes-news-impact":

Tenga en cuenta que, aunque hemos usado el símbolo "/" en el nombre de la rama al crearla, este símbolo se sustituirá automáticamente por "-" en la rama real. Aunque Git parece no tener tales restricciones, y podemos crear fácilmente una nueva rama con una barra en su nombre a través de la interfaz web, el MetaEditor prohíbe el uso de cualquier carácter excepto letras latinas y guión al crear una rama. 

Vamos a intentar comprobar hasta qué punto resulta fundamental seguir una restricción de este tipo. Para ello, crearemos una nueva rama a través de la interfaz web del repositorio MQL5 Algo Forge utilizando una barra en el nombre, por ejemplo, "fixes/cast-warning". Para ello, iremos a Branches y haremos clic en el botón para crear una nueva rama a partir de una rama main ya existente:

La rama se ha creado correctamente:

Sin embargo, si ejecutamos el comando Pull en el MetaEditor, nos encontraremos con este mensaje de error:

No obstante, la nueva rama con una barra en su nombre aparece en la lista de ramas en el MetaEditor, y alternar a ella no causa ningún mensaje de error:

Una vez anotada esta característica, cambiaremos de nuevo a la rama fixes-news-impact e introduciremos correcciones que eliminen temporalmente la causa del error:

Después de esto, el archivo indicador se compilará sin errores y podremos confirmar nuestras ediciones a través del menú contextual "Git Commit": 

En el cuadro de diálogo que aparece, comprobaremos la composición de los archivos cuyos cambios queremos confirmar. Para los cambios en un único archivo, esta comprobación será muy sencilla. También será muy conveniente añadir un comentario que describa qué cambios introduce esta confirmación. Tras asegurarnos de que todo esté correcto, haremos clic en OK.

Después de eso, las ediciones realizadas se enviarán a nuestro repositorio superior en el repositorio MQL5 Algo Forge, que será una bifurcación del repositorio original del proyecto SmartATR. Ya podemos utilizar la versión corregida del indicador en la computadora local y su copia de seguridad también estará presente en nuestro almacenamiento. A continuación, si así lo deseamos, podremos enviar al autor del repositorio original una solicitud para fusionar nuestras ediciones haciendo clic en el botón "New pull request" de la interfaz web en la página Branches:

Pero aún es pronto para hacerlo, ya que no hemos realizado ninguna mejora útil en el código del proyecto, sino que solo hemos desactivado una parte de la funcionalidad en cuya implementación detectamos un error. Así que no vamos a crear un Pull Request en este momento.

Ya está todo listo para utilizar el indicador SmartATR en nuestro proyecto Simple Candles.

Conectamos el indicador

Siguiendo las reglas aceptadas, para realizar cambios en el proyecto Simple Candles, crearemos una nueva rama article-19436-forge3 en el repositorio del proyecto a partir de la rama develop. Para cambiar un poco, los haremos en la interfaz web del repositorio MQL5 Algo Forge, como hemos descrito anteriormente.

Para que la nueva rama aparezca en el clon del repositorio en nuestra computadora local, ejecutaremos el comando "Git Pull" desde el menú contextual del repositorio del proyecto en el MetaEditor y cambiaremos a la rama article-19436-forge3 que aparecerá.

Como planeamos utilizar este indicador en una estrategia comercial, lo añadiremos al archivo de clase de la estrategia comercial utilizada SimpleCandlesStrategy.mqh. Asimismo, añadiremos una variable a la lista de campos de clase para almacenar el manejador de este indicador:

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

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

A continuación, en el constructor de la clase llamaremos a la función iCustom(), a la que pasaremos como parámetros el símbolo, el marco temporal, la ruta al archivo del indicador y la lista de parámetros para el propio 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
                     );

      // ...
   }
}

Observe cómo especificamos la ruta al archivo del indicador. Comenzamos con el nombre de la carpeta Shared Projects, luego el nombre de la carpeta del repositorio de proyectos SmartATR y, al final, el nombre del archivo del indicador SmartATR.ex5. La extensión .ex5 puede omitirse, pero la hemos dejado a propósito para que quede claro dónde está el nombre de la carpeta y dónde está el nombre del propio indicador.

Hay otro matiz a considerar al trabajar con los proyectos de la carpeta Shared Projects, a saber, no importa si se trata de proyectos propios o de terceros: durante la compilación todos los archivos ejecutables se crearán no en la carpeta del repositorio, ¡sino en una ubicación diferente! Esto se debe a que la carpeta Shared Projects se encuentra en la carpeta raíz de la carpeta de datos del terminal, es decir, MQL5/Shared Projects. Por un lado, esto es algo bueno, ya que el sistema de control de versiones no intentará ofrecernos la adición de archivos de inicio al índice. Por otra parte, al principio puede resultar un poco desorientador: ¿dónde debemos buscar los archivos compilados del asesor experto y los indicadores?

Resulta que en las carpetas correspondientes a los distintos tipos de programas (MQL5/Experts para los asesores expertos, MQL5/Indicators para los indicadores, etc.), durante la compilación se crean automáticamente carpetas anidadas Shared Projects con las subcarpetas de los proyectos. Aquí es donde van los archivos compilados. Es decir, si compilamos el archivo fuente en la dirección MQL5/Shared Projects/SmartATR.mq5, entonces el archivo de inicio del indicador debería encontrarse en la dirección MQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5.

Resulta que al llamar a la función iCustom(), deberemos especificar la ruta del archivo de indicador relativa a la carpeta MQL5/Indicators.

Bueno, vamos a compilar ahora el archivo de asesor SimpleCandles.mq5, que utiliza instancias de estrategias comerciales con el indicador conectado, y a ejecutarlo en el simulador de estrategias para probarlo. En los registros podemos ver los siguientes mensajes:

Es decir, el código del indicador se ha cargado correctamente, se ha inicializado y se puede utilizar en el trabajo del asesor experto. Hasta ahora, el indicador no se usa de ninguna manera, ya que queríamos demostrar en primer lugar la posibilidad de utilizarlo. Bueno, tal vez lleguemos a su uso real un poco más tarde. Luego confirmaremos nuestras ediciones y enviaremos los cambios al repositorio MQL5 Algo Forge.

Conclusión

Hoy hemos intentado demostrar que el cambio a MQL5 Algo Forge descubre nuevas oportunidades totalmente fundamentales para que los desarrolladores organicen su flujo de trabajo. Si antes considerábamos que trabajábamos con nuestros propios repositorios en un modo "cerrado", ahora hemos conseguido integrar con éxito en el proyecto una biblioteca externa procedente de un repositorio de terceros.

La clave reside en utilizar un flujo de trabajo adecuado creando una bifurcación: una copia personal del repositorio de otra persona que permite realizar cambios libremente y mantener la sincronización con el original. La aplicación práctica de la conexión de la biblioteca SmartATR al proyecto Simple Candles ha confirmado que todo el proceso (desde la búsqueda de un repositorio y la creación de un bifurcación, hasta el uso directo del código en un asesor comercial) funciona.

La integración se realiza utilizando las capacidades actuales del MetaEditor, sin esperar a sus futuras actualizaciones. Las limitaciones actuales del MetaEditor (ausencia de una forma directa de trabajar con otros repositorios, peculiaridades del trabajo con las ramas) se pueden compensar utilizando la interfaz web del repositorio MQL5 Algo Forge y los comandos de consola Git. Así que el sistema en su conjunto está listo para usar, y algunas deficiencias de la interfaz no suponen un obstáculo para el trabajo en toda regla, aunque a veces causan molestias notables.

Pero no vamos a detenernos ahí. Seguiremos utilizando repositorios para compartir código de distintos proyectos y comunicar las experiencias que surjan por el camino.

Gracias por su atención y hasta pronto.