Galería de interfaces de usuario escritas en MQL - página 24

Nuevo comentario
 
hini #:
¿Cómo deshacerse de las más de cinco mil advertencias que se generan al compilar, muchas de ellas en archivos de lenguaje de marcado?
No se puede. Es técnicamente inevitable porque escribimos código de marcado en la matriz de cadenas. Este tipo de datos es convencionalmente adecuado para escribir cualquier valor y palabra.

Al final, no importa, porque el constructor es perfectamente capaz de distinguir entre palabras clave, nombres y valores numéricos.

No hay pérdida de datos debido a este enfoque.
 
Teóricamente se podría escribir (int) o (double) antes de cada valor numérico, pero eso lo dejo a criterio del usuario.
 
Tenemos que "pisarle la garganta" al compilador, pero al final ganamos). No es para tanto.


Que conste. Respeto las reglas de programación y las advertencias del compilador, pero en este caso no he encontrado una solución mejor. Me doy cuenta de que a algunos no les gustará este enfoque, pero resultó ser el más óptimo. E inofensivo.
 
Realmente espero que mañana será capaz de publicar una actualización y los que quieren finalmente comenzar a crear su propia interfaz. Haré todo lo posible.
 
Реter Konow advertencias del compilador, pero en este caso no pude encontrar una solución mejor. Me doy cuenta de que a algunos no les gustará este enfoque, pero resultó ser el más óptimo. E inofensivo.
Una pequeña anécdota:

Cuando se planteó la cuestión de dónde escribir el código de marcado, me enfrenté a dos opciones principales - en matriz de cadenas o en un archivo. Tras sopesar los pros y los contras que se me ocurrieron, decidí que un array es mucho mejor por varias razones. En primer lugar, la inicialización instantánea y el procesamiento del contenido de la matriz por el código del constructor. En segundo lugar, acceso rapidísimo a los atributos y propiedades individuales de los controles desde el constructor/motor para leer/sobrescribir si es necesario (con un fichero sería un problema enorme). Y en tercer lugar, es mucho más fácil enviar un array a un recurso a través de un evento OnChartEvent() personalizado. Por eso elegimos un array. Y las advertencias... bueno, qué se le va a hacer. Siempre hay que sacrificar algo para conseguir el objetivo.

 
Corrección del texto anterior: no se reenvía por recurso, sino por trozos de cadenas compuestas.
 
Bueno, y la razón total que pondrá el clavo final en la "tapa del ataúd" de la idea de que el marcado podría ser escrito en un archivo de texto:

Un archivo .txt no se puede compilar para asegurarse de que no hay errores tipográficos groseros. Esto significa que si el usuario mete la pata hasta el fondo con comas, comillas, espacios, etc., NO LO SABRÁ POR EL COMPILADOR.

Sólo después de fallar en la construcción de la interfaz tendrá que darse cuenta de que ha escrito mal el código y entrar a buscar y encontrar hasta la última errata. Si se le escapa una sola, tendrá que repetir el proceso.

Este es un precio increíblemente caro por la ausencia de advertencias del compilador.

Es por eso que en MQL, la variante con matriz de cadenas para el código de marcado no tiene alternativas y no se puede utilizar. Y las advertencias del compilador deben tomarse como un hecho.
 
P.D. El compilador avisa incluso cuando una palabra clave está mal escrita. A veces el intellisense ayuda. En un archivo .txt, si escribes mal las palabras clave, no lo sabrás. Así que no hay ninguna ventaja práctica de un archivo sobre una matriz.

Espero haber explicado en detalle por qué no debes deshacerte de las advertencias del compilador en este caso particular.

Buenos días a todos.

 
Реter Konow las advertencias del compilador en este caso concreto.

Hola a todos.

Vale, entendido.
 
¿Es esta parte del código en el corazón del constructor
Archivos adjuntos:
Snipaste_2024-06-25_09-04-41.png  7 kb
1...171819202122232425262728293031...49
Nuevo comentario