Discusión sobre el artículo "El lenguaje MQL como medio de marcado de la interfaz gráfica de programas MQL. Parte 1"
He vuelto a leer detenidamente el artículo y no he encontrado el concepto de lenguaje de marcado. Hay algunas ideas sobre implementaciones en otros lenguajes y posibilidades de tomar prestadas algunas librerías, pero el autor aún no ha construido el concepto. Sin él, no tiene sentido tomar prestado o modificar nada.
El concepto debería describirse con palabras sencillas y claras, sin códigos, y explicar la esencia de la tecnología: qué y cómo debería funcionar. Pero en el artículo hay algunos códigos, ejemplos, etc. .... ¿De qué tratan?
El capítulo:"Diseño de un lenguaje de marcado" no contiene el concepto de lenguaje de marcado. Autor, presta atención a que no escribiste nada sobre la tecnología de los lenguajes de marcas, sino que entraste directamente en algunos detalles, cómo, dónde y qué se puede tomar prestado. Luego, hablas de alguna jerarquía de controladores (que en realidad no describes) y entras en detalles no relacionados.
Es necesario partir del concepto de la tecnología que se está creando, y aún no existe tal concepto.
Buen artículo y buenas decisiones, agradable de leer.
Para que sea 5 +, un poco no era suficiente - una breve revisión de "lo que es malo / bueno en el resto del mundo" :-) El autor claramente lo posee y escribe no de la nada ...
Espero de las siguientes partes: algo así como Geometría y Gestores de estilo (esto es para deshacerse del cálculo de coordenadas y distribución de colores), el trabajo de GUI en términos de interacción con la lógica básica.
otra junta.
¿Cuántas piezas serán, 38 o 55?
¿Y cuántas partes habrá, 38 o 55?
no todo el mundo puede escribir "Guerra y Paz" en los artículos en el foro MQL.
El autor de más de un ciclo de 4 artículos no se ha visto antes ))))
El material del artículo parece ser bien leído, pero hay cierta incomodidad, en algún lugar no sé en qué basarse - XAML se toma como base? - por desgracia, no lo he estudiado y no lo uso, así como excepto WinForms y no utilizar otras características de C #.
En general, interesante, vamos a ver lo que sigue, el único deseo es un poco más fotos, en mi opinión el material se ve muy seco si sólo leerlo.
La profesionalidad del autor inspira esperanzas, siempre que pueda manejar el concepto y la implementación de principio a fin. El primer artículo insinúa la intención de tomar una biblioteca ya hecha, modificarla y convertirla en un lenguaje de marcado. No creo en el sentido de tal solución. La biblioteca en sí es limitada, y el lenguaje de marcado será débil. Sin un nivel cualitativamente nuevo de la tecnología y los controladores en el lienzo - "piel de oveja" no vale la pena, y si el autor retoma los elementos dibujados - es necesario volver a hacer lo básico. Todo esto requiere un conocimiento muy profundo de la tecnología y un montón de tiempo. A juzgar por la forma en que el autor se aferra a los nombres de las variables (que serán miles), la sintaxis, las reglas - me temo, no llegará a la finalización....
¡PERO! Este es sólo el primer artículo. Vamos a ver ...
no todo el mundo puede escribir "Guerra y Paz" en el foro MQL en artículos
el autor de más de un ciclo de 4 artículos no se ha visto antes ))))
El material del artículo parece ser bien leído, pero hay cierta incomodidad, en algún lugar no sé en qué basarse - XAML se toma como base ... - por desgracia, no lo he estudiado y no lo uso, así como excepto WinForms y no utilizar otras características de C #
En general, interesante, vamos a ver lo que sigue, el único deseo es un poco más fotos, en mi opinión el material se ve muy seco si sólo leerlo.
Intenté estudiar XAML, sólo desde el principio, y no entendí la broma de humor - por qué estudiar un lenguaje más, e incluso extremadamente especializado, que, además, no amplía las posibilidades, sino que las estrecha. De todas formas, algún día querrás "retocar" algo del funcionamiento del programa o flexibilizar la interfaz, así que tendrás que estudiar cómo se hace todo de forma directa y sin almohadillas. El beneficio del lenguaje de marcas es insignificante, y si tienes en cuenta que aún tienes que aprenderlo, es muy dudoso. O no he entendido la ideología de XAML.
Y yo intenté estudiar XAML, sólo desde el principio, y no entendí la broma del humor: para qué estudiar otro lenguaje, y encima muy poco especializado, que además no amplía las posibilidades, sino que las estrecha. De todas formas, algún día querrás "retocar" algo del funcionamiento del programa o flexibilizar la interfaz, así que tendrás que estudiar cómo se hace todo de forma directa y sin almohadillas. El beneficio del lenguaje de marcas es insignificante, y si tienes en cuenta que aún tienes que aprenderlo, es muy dudoso. O no he entendido la ideología de XAML.
vamos a esperar a que el autor del artículo, puede dar la dirección de búsqueda de lo que es conveniente XAML, tal vez voy a leer, aunque lo principal, de hecho - ¿cuál será el resultado del artículo, lo conveniente y funcional que será, en esta etapa estoy satisfecho con SB para primitivas gráficas - las fuentes están disponibles y legible.
SZY: sobre nuevos lenguajes, bueno, todo es relativo, quería usar SB para guardar un par de gráficos en .bmp... no lo entendí en un día, escupí google, me familiaricé con Google Charts en 15 minutos y en vez de .bmp genero .html - incluso offline puedes ver los gráficos, es decir, ¡la usabilidad es la clave del uso! ;)
Y yo intenté estudiar XAML, sólo desde el principio, y no entendí la broma del humor: para qué estudiar otro lenguaje, y encima muy poco especializado, que además no amplía las posibilidades, sino que las estrecha. De todas formas, algún día querrás "retocar" algo del funcionamiento del programa o flexibilizar la interfaz, así que tendrás que estudiar cómo se hace todo de forma directa y sin almohadillas. El beneficio del lenguaje de marcas es insignificante, y si tienes en cuenta que aún tienes que aprenderlo, es muy dudoso. O no he entendido la ideología de XAML.
El gran valor de XAML es que simplifica el desarrollo de todo tipo de ventanas de diálogo y otras tonterías. En MFC no es fácil crear una lista que difiera en apariencia de la estándar, hay que esforzarse, pero aquí se hace una o dos veces. He estado trasteando con ello, es alucinante, pero si necesitas hacer interfaces, puedes dominarlo. Y no necesitas aprenderlo, es sólo un pedazo de Sharp. Realmente empieza a ahorrar tiempo, no inmediatamente, pero a medida que lo aprendes.
Gente, ¿por qué os amontonáis contra una persona desde el primer artículo cuando no podéis ver el resultado? Nunca he escrito comentarios aquí, pero el tuyo me ha hecho hacerlo.
No soy un programador profesional, sino un aficionado. Y muchos artículos aquí, incluso los fallidos, me hacen buscar mejores soluciones, estudiar más a fondo los lenguajes de programación. Entender por qué el autor ha implementado esta forma concreta de resolver el problema. Para aplicar algo en mis propios desarrollos. Cualquier artículo me hace aumentar la cantidad de conocimientos muchas veces más que si me limito a leer libros y documentación.
He aquí un ejemplo sencillo. Aquí ya hay varios artículos sobre GUI, pero todo está implementado, aunque con la ayuda de clases, pero en estilo procedural. Es engorroso e inconveniente. Tienes que entender todo el código de principio a fin. Eso me hizo fijarme en otros lenguajes, como C++, C#, donde anulando un método virtual, por ejemplo doubleclick, puedes implementar lo que quieras sin meterte en líos.
Empecé a estudiar patrones de diseño, estructuras de datos dinámicas, como en mql no hay delegados, tuve que entender que es este plato y con que se come. Tuve que reescribir todas las clases estándar. Empecé desde el principio, con CObject. Al final escribí una simple implementación del manejo de eventos OnTradeTransaction, OnChartEvent, OnTimer usando "real" OOP. No estoy familiarizado con el marcado XAML, cuando traté de estudiarlo me pareció muy tedioso, pero ahora me pondré a ello para entender lo que el autor quiere transmitir, y tuve la oportunidad de implementar algunas de sus ideas por mí mismo.
Así que antes de criticar duramente cualquier artículo, piensa que hay gente como yo que necesita una visión diferente sobre el mismo tema. Sugiere, orienta, si tienes conocimientos más profundos. Haz equipo. Será más productivo que cagarse en un artículo.
- www.mql5.com
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado El lenguaje MQL como medio de marcado de la interfaz gráfica de programas MQL. Parte 1:
En el presente artículo, presentamos un nuevo concepto para la descripción de la interfaz de ventana de los programas MQL con la ayuda de las construcciones del lenguaje MQL. Las clases especiales transforman el marcado visual de MQL en elementos de GUI, permitiendo de controlarlos, ajustar sus propiedades y procesar eventos de forma unificada. Asimismo, mostraremos ejemplos de uso del marcado en las ventanas de diálogo y los elementos de la biblioteca estándar.
¿Para qué separan la disposición del código y la describen en un lenguaje especial? Estas son las principales ventajas de este enfoque.
Para el entorno MQL, se ha intentado muchas veces solucionar ciertas de estas tareas. En concreto, el constructor visual de ventanas de diálogo se presenta en el artículo MQL para "Dummies": Cómo Diseñar y Construir Clases de Objetos, y funciona usando como base la biblioteca MasterWindows. Pero los métodos de disposición y la lista de tipos de elementos soportados se ven fuertemente limitados en él.
Podrá encontrar un sistema de disposición más avanzado, pero sin diseñador visual, en los artículos Aplicación de los contenedores para componer la interfaz gráfica: clase CBox y clase CGrid. Esta da soporte a todos los elementos estándar de gestión y de otro tipo heredados de CWndObj o CWndContainer, sin embargo, sigue dejando al usuario la programación rutinaria de creación y ubicación de los componentes.
Desde un punto de vista conceptual, este enfoque con los contenedores es muy tecnológico (basta con indicar su popularidad en casi todos los lenguajes de marcado), y por eso vamos a utilizarlo. En uno de nuestros anteriores artículos (Implementando OLAP en la negociación (Parte 2): Visualización de los resultados del análisis interactivo de los datos multidimensionales), propusimos una modificación de los contenedores CBox y CGrid, así como algunos elementos de gestión para dar soporte de las propiedades de "elasticidad". A continuación, vamos a aprovechar este tiempo invertido y mejorarlos para solucionar las tareas de ubicación automática de elementos usando como ejemplo los objetos de la biblioteca estándar.
Autor: Stanislav Korotky