Interfaz gráfica de usuario de origen colectivo. Prueba beta abierta. - página 48

 

Pedro, puedes tratarme como quieras, estás en tu derecho, pero déjate aconsejar por un camarada un poco más experimentado.

#include <GUI_DRIVE.mqh>
#include "..\Files\CORES.mqh"
#include "..\Files\Internal_API.mqh" 

El archivoGUI_DRIVE.mqh se conecta primero en el código. No se declara nada antes.

Si lo compila obtendrá un error de falta de G_CORE, ¡y es lógico porque el array no está declarado en este archivo!

¿Conclusión? Bien, la conclusión es elemental: el array debe ser declarado en este archivo. Al final, es este archivo el que opera con esta matriz, ¡porque este archivo es el "motor"! Por lo tanto, la declaración del propio array en él es correcta, según el contexto de uso.

El siguiente archivo,CORES.mqh , rellena la matriz con la descripción de los elementos del formulario.

Por supuesto, al compilar el propio EA con estos archivos, si el array se declara en el primer archivo, no habrá problemas de compilación, porque al compilar el segundo archivo, el array ya será visible en el contexto del programa.

Pero lo que estamos diciendo es que cada archivo debe compilar sin errores. Dado que el segundo archivo llena el array G_CORE con elementos, naturalmente encontraremos un error al compilar este archivo, si el array no está declarado.

Y aquí usamos, como dijo Alejandro, un talón.

Pyotr, eres un gran aficionado a las definiciones, así que sabrás lo que pasa.

En el archivo GUI_DRIVE se declara un array global de elementos del kernel G_CORE, tras lo cual el archivo debería compilar sin errores.

Entonces en este archivo se añade una definición.

#define __DRIVE__

Pase a la ficha de los núcleos. Antes de declarar un array, utilice el preprocesador de compilación.

#ifndef __DRIVE__
int G_CORE[][prop_limit];
#endif

Y luego se llena la matriz. Por supuesto, tendrás que cambiar un poco la forma de llenar el array, para hacerlo sin declaración.

Creo que has captado lo esencial: si se compila el archivo CORES, el valor por defecto__DRIVE__ desaparece y se compila el código de la declaración del array y todo funciona bien.

Si el archivo se compila como parte del EA, después de compilar el primer archivo, se declara la definición y en el segundo archivo no se declara el array porque el compilador "corta" este trozo de código.

Espero haber sido claro.

Lo repetiré de nuevo: todos los archivos deben compilar sin errores. Si tiene dependencias, debe prever adecuadamente su ubicación y añadir procesadores de recompilación según sea necesario.

Cuando todos los archivos se compilan sin errores, se tiene más confianza en la integridad de todo el sistema.

Además, no olvides añadir una propiedad en cada archivo:

#property strict

Esta propiedad proporciona un control más estricto del código.

 
Esto tiene poco sentido práctico. Si cada archivo se compila sin errores, independientemente de la integridad del conjunto, el usuario podría perder fácilmente la conexión de uno de los archivos. Es fácil olvidarlo.

De todos modos, es tan insignificante que no voy a perder el tiempo con ello. Esto es un completo disparate. Es una tontería.
 
Sí, puedes hacer que cada archivo se compile por separado sin errores manipulando el preprocesador.

Pero ahí está el error. Son partes de un todo y no deben "retratar" la independencia de otras partes. Y de hecho, el usuario puede decidir que no se necesitan todos los archivos, porque funciona tal cual.

¿Perder el tiempo en una actividad que tiene un sentido muy dudoso? ¿A quién quiero engañar? ¿El compilador?

Los compañeros "experimentados" parecen tener miedo de su voz severa y creen que siempre tiene razón en todo. Así que intentan adaptarse, aunque no tenga sentido.

Tenía miles de advertencias en mi código de lenguaje de marcas porque tenía que poner (sring) antes de las constantes. Me imagino cómo sería el código si pusiera una conversión de tipo antes de cada número. Pero al menos no habría advertencias.
 
Реter Konow:
Sí, manipulando el preprocesador puedes hacer que cada archivo compile por separado sin errores.

Pero ahí está el error. Son partes de un todo y no deben "retratar" la independencia de otras partes. Y de hecho, el usuario puede decidir que no se necesitan todos los archivos, porque funciona tal cual.

¿Perder el tiempo en una actividad que tiene un sentido muy dudoso? ¿A quién quiero engañar? ¿El compilador?

Los compañeros "experimentados" parecen tener miedo de su voz severa y creen que siempre tiene razón en todo. Así que intentan adaptarse, aunque no tenga sentido.

Tenía miles de advertencias en mi código de lenguaje de marcas porque tenía que poner (sring) antes de las constantes. Me imagino cómo sería el código si pusiera una conversión de tipo antes de cada número. Pero al menos no habría advertencias.

Hay algunos compañeros que están escribiendo un software independiente que cambia ligeramente la interfaz del propio meta-editor, ¡sólo para facilitar su uso!

Esta norma es como utilizar un teclado, en lugar de escribir las letras en código morse a través de un chirriador. Los stubs no cambian nada, excepto el cambio constante entre archivos en tiempo de compilación. Pero un stub son 2 líneas de código. Cuánto tiempo pasaríamos en esta navegación sólo para pulsar un botón. Y cuántas veces le daremos la vuelta al 7 y qué será más racional para no perder la vida tecleando letras por un chirriador

Tenga en cuenta que no estamos hablando de objetos o clases, sólo estamos hablando de ahorrar tiempo. Su tiempo... Y tú mismo puedes elaborar una norma para escribirlas.
 
Por no hablar de la codificación en ruso, que está discriminada por defecto por el entorno de desarrollo en inglés. ¿También para adaptarme y dejar a mi cerebro un mísero 30% de rendimiento, mientras que puedo utilizar todo el 100% en ruso?

Esto en cuanto al precio de la "profesionalidad".
 
Реter Konow:
Por no hablar de la codificación en ruso, que por defecto está discriminada por el entorno de desarrollo en inglés. ¿Debo adaptarme también y dejar a mi cerebro un mísero 30% de rendimiento, mientras que puedo utilizar todo el 100% en ruso?

Esto en cuanto al precio de la "profesionalidad".

Los profesionales utilizan sus propios tipos de datos en su código. En general, no importa en qué idioma estén.

Pero si una función espera un número entero en este orden: Aceptar (ancho, alto).

En su lugar, accidentalmente lo mezclamos y escribimos

Aceptar (altura, anchura) - entonces el propio copyulator dice que tenemos una confusión aquí. Si te funciona, tampoco se trata de la lengua ni de los objetos. Se trata de no tener que buscar este error por sí mismo

 
Alexandr Andreev:

En el código profesional, los individuos utilizan sus propios tipos de datos. No importa realmente en qué idioma estén.

Pero si una función espera un entero en este orden: Aceptar (ancho, alto).

En su lugar, accidentalmente lo mezclamos y escribimos

Aceptar (altura, anchura) - entonces el propio copyulator dice que tenemos una confusión aquí. Si te funciona, tampoco se trata de la lengua ni de los objetos. Se trata de no tener que buscar este error por sí mismo.

Se trata de una rama para probar soluciones ya hechas y comunicarlas a los usuarios.

Necesito probadores constructivos, no "profesionales" ambiciosos que busquen algo de lo que quejarse.

No voy a discutir cuestiones abstractas. ¿Conectaste el panel ensamblado, encontraste errores y los reportaste? ¡Muchas gracias! Hacerse el listo y meterse con lo que no se entiende: adiós.
 
Señores inteligentes, ustedes no deben estar aquí.

Para los que no han dirigido el editor y no han conectado el panel, pero están "enseñando", la conversación es corta.

Los demás, ¡bienvenidos!
 
Алексей Барбашин:

Pedro, puedes tratarme como quieras, estás en tu derecho, pero sigue el consejo de un camarada un poco más experimentado.

.......

Tampoco olvides añadir una propiedad en cada archivo:

#property strict

Esta propiedad proporciona un control más estricto del código.

es para 5 - ¡siempre es lo mismo allí!

aunque en general estoy de acuerdo: un montón de advertencias en la compilación no aumenta la confianza en el código.

 
Igor Zakharov:

está hecho para cinco - ¡siempre es estricto!

aunque estoy de acuerdo en general: un montón de advertencias en tiempo de compilación no aumenta la confianza en el código.

Eliminaré las advertencias. Temporalmente.