Discusión sobre el artículo "Controles gráficos personalizados. Parte 3. Formularios"
Un trabajo bueno y útil, Dimitri. Hay una sugerencia para la cuarta parte: "Asistente de formularios" o "Editor visual de formularios" ¿Qué te parece?
Respeto, Dimitri. Has hecho un gran trabajo.
Por favor, acepta algunas críticas para la próxima versión de clases v4.
1. no hay suficiente abstracción en el proyecto básico. Resulta que cada control que tienes actúa como una unidad independiente. Como resultado, no puedes combinarlos en un array, por ejemplo.
2. Cada clase de un elemento tiene ahora, en general, su propio conjunto único de funciones. Esto no es bueno. Debería haber un ancestro común cuyas funciones fueran simplemente anuladas en los descendientes. Sobre todo porque hay tantas funciones con el mismo nombre en las clases actuales. ¿qué impide hacer un ancestro común?
3. si aparece una clase base, será posible ocultar el manejo de eventos dentro de los descendientes, en lugar de ponerlos todos fuera en el formulario. para hacer una cascada de eventos dentro de los objetos (similar a CSS en la web).
Pero en general, las tres partes del artículo son dignas de premio, sobre todo me han gustado los "empujoncitos" al pulsar botones y sus respuestas interactivas a las pulsaciones dependiendo del estado del elemento.
PD.
Y el menú multinivel aún lo terminas, no es necesario un artículo aparte sobre él, demasiado gordo para una tarea tan pequeña como para escribir un artículo nuevo. Que sea sólo una actualización en la versión v4.
La clase de árbol CTreeCtrl se puede tomar del artículo https://www.mql5.com/es/articles/272 o CTreeNode ofrecido en el kit MT.
- 2011.03.16
- o_O
- www.mql5.com
Un trabajo bueno y útil, Dimitri. Hay una sugerencia para la cuarta parte: "Asistente de Formularios" o "Editor Visual de Formularios" ¿Qué te parece?
Personalmente, lo veo positivamente. ¿Pero es necesario? Visual sólo simplifica la colocación de objetos. Si lo haces bien, necesitas vincular la generación de código para los objetos creados, la vinculación de variables o clases al objeto. Y lo más importante, el manejo de eventos.
Pero en estas clases no abstractas no se puede hacer. Son muy manuales. En muchos lugares es necesario escribir objetos recién creados y su procesamiento.
Para los eventos, por ejemplo, no hay tal división en el sistema y el usuario - como Draw (sistema básico) y OnDraw - adición del usuario con su propio dibujo.
En otras estructuras (por ejemplo Joomla!) No sólo hay una función personalizada OnDraw. Y se divide en dos - BeforDraw y AfterDraw. Es decir, el programador puede manejar el evento del sistema EVENT_DRAW - tanto antes del inicio del dibujo del sistema y después de su finalización.
Respeto, Dimitri. Has hecho un gran trabajo.
Por favor, acepta algunas críticas para la próxima versión de clases v4.
1. no hay suficiente abstracción en el proyecto básico. Resulta que cada control que tienes actúa como una unidad independiente. Como resultado, no puedes combinarlos en un array, por ejemplo.
2. Cada clase de un elemento tiene ahora, en general, su propio conjunto único de funciones. Esto no es bueno. Debería haber un ancestro común cuyas funciones fueran simplemente anuladas en los descendientes. Sobre todo porque hay tantas funciones con el mismo nombre en las clases actuales. ¿qué impide hacer un ancestro común?
3. si aparece una clase base, será posible ocultar el manejo de eventos dentro de los descendientes, en lugar de ponerlos todos fuera en el formulario. para hacer una cascada de eventos dentro de los objetos (similar a CSS en la web).
Pero en general, las tres partes del artículo son dignas de premio, sobre todo me han gustado los "empujoncitos" al pulsar botones y sus respuestas interactivas a las pulsaciones dependiendo del estado del elemento.
PD.
4. Un menú multinivel aún lo terminas, un artículo aparte sobre ello no es necesario, demasiado gordo para una tarea tan pequeña como para escribir un nuevo artículo. Que sea sólo una actualización en la versión v4.
La clase de árbol CTreeCtrl se puede tomar del artículo https://www.mql5.com/es/articles/272 o CTreeNode ofrecido en el kit MT.
1- Puedes reunir controles de un solo tipo en un array. ¿Por qué querrías reunir controles disímiles en un array?
2. Si utilizas una clase base (una para todos los controles), significa que debe tener todos los métodos que pueda tener cualquiera de las subclases. Con clases independientes, en la lista desplegable de métodos (durante el desarrollo), sólo tenemos los métodos que realmente existen en la clase. En mi opinión, este es un punto muy importante. Me imagino a alguien sentado intentando llamar al método SetWidth() para una barra de desplazamiento vertical.
El segundo argumento - todas las clases están comentadas para doxygen, si hay una clase base y subclases, no habrá una estructuración tan obvia en la documentación.
Trato de hacer soluciones listas para que puedan ser utilizadas con los "ojos cerrados". Para acelerar el proceso de creación de un nuevo control, se puede utilizar una plantilla con todos los métodos obligatorios.
3. No entiendo muy bien. Si un control tiene otro control dentro, su manejo de eventos está oculto. En cualquier caso, tendrás que llamar a Event() para cada control.
4. No sé, quizás... Tengo mi propia clase especialmente diseñada para la creación de menús, no es necesario llamar a AddNode(), se llama a AddItem(), y el nivel viene determinado por el número de espacios con los que empieza el nombre del elemento. El proceso de creación de un árbol es muy claro. Hasta ahora funciona con la visualización en el comentario y el control de teclas. En general, se pueden hacer varios menús de árbol: 1) como un menú principal normal con pestañas desplegables, 2) mostrar los elementos de una pestaña y el camino hasta la parte superior, 3) con visualización en árbol (como windos explorer).
1. Personalmente, lo veo positivo. Pero, ¿es necesario? La visualización sólo simplifica la colocación de objetos. Si lo haces bien, necesitas vincular la generación de código para los objetos creados, vinculando variables o clases al objeto. Y lo más importante, el procesamiento de eventos.
2. Pero en estas clases no abstractas no se puede hacer. Son muy manuales. Es necesario escribir en muchos lugares objetos recién creados y su procesamiento.
Para los eventos, por ejemplo, no hay tal división en sistema y usuario - como Draw (sistema básico) y OnDraw - una adición del usuario con su propio dibujo.
En otras estructuras (por ejemplo Joomla!) no sólo hay una función personalizada OnDraw. Y se divide en dos - BeforDraw y AfterDraw. Es decir, el programador puede manejar el evento del sistema EVENT_DRAW - tanto antes del inicio del dibujo del sistema y después de su finalización.
1. Será posible generar automáticamente el código para manejar los eventos de los controles y obtener funciones de eventos para todos los controles, como HScrollBar1_OnChange()....
2. Todavía no hay eventos, por ejemplo, cuando los valores se establecen mediante programación, los eventos se generan sólo cuando los valores son introducidos por el usuario. Esto es un mínimo suficiente, nada extra. De lo contrario, alguien que esté aprendiendo a programar por su cuenta se verá inundado de eventos.
Un trabajo bueno y útil, Dimitri. Hay una sugerencia para la cuarta parte: "Asistente de formularios" o "Editor visual de formularios". ¿Cómo lo ves?
... Hay una sugerencia para la parte 4: "Asistente de formularios" o "Editor visual de formularios" ¿Qué te parece?
1. Los controles de un solo tipo pueden reunirse en un conjunto. ¿Por qué reunir diferentes tipos de controles en un array?
Para llevar todo a un bucle y deshacerse de tipos específicos en el servicio de eventos.
2. Si utilizas una clase base (una para todos los controles), significa que debe tener todos los métodos que pueda tener cualquiera de las subclases. Con clases independientes, en la lista desplegable de métodos (durante el desarrollo), sólo tenemos los métodos que realmente existen en la clase. En mi opinión, este es un punto muy importante. Me imagino a alguien sentado intentando llamar al método SetWidth() para una barra de desplazamiento vertical.
Todas las funciones de la clase base son tapones vacíos con una funcionalidad general mínima. Incluso si alguien sin saberlo llama a una función no relacionada para un elemento, absolutamente nada malo sucederá. ese es el poder de la programación orientada a objetos. Polimorfismo.
El segundo argumento - todas las clases son comentadas por doxygen, si hay una clase base y subclases, no habrá una estructuración tan obvia en la documentación.
la habrá. sólo que será diferente... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. meter todo en un bucle y deshacerse de tipos específicos en el servicio de eventos.
2. el punto es que la clase base - no tiene implementación de funciones de acciones específicas. todas las funciones en la clase base son tapones vacíos con funcionalidad general mínima. Incluso si alguien sin saberlo llama a una función no relacionada para un elemento, absolutamente nada malo sucederá. este es el poder de la POO. Polimorfismo, sin embargo.
3. lo hará. sólo que será diferente.... :)
1. ¿Eso es todo? Por el bien de este meterse con el punto 2 - método de volcado?
Alternativas:
1) La necesidad de añadir manualmente una llamada Event() para cada clase (que consiste en copiar con el ratón una línea y cambiar unas letras a la izquierda del punto) y al mismo tiempo, en la lista de métodos de cada clase tenemos sólo los métodos de trabajo correspondientes a esta clase, hizo clic en el punto, la lista apareció y todo está claro.
2) Procesamiento automático de Event() de todas las clases, mientras que todavía habrá que llamar a una función desde OnChartEvent(), y por otro lado: un volcado de métodos en la lista. Además, tendrías que destruir punteros en el deinit.
Mira un poco más profundo y más allá, por qué todos los Event() deben ser procesados en un bucle, cada control debe tener sus propias acciones para su Event(), los controles no son sólo para introducir un valor y no sólo para hacer que todo se mueva y parpadee en la pantalla, sino también (en la medida principal) para utilizar los valores introducidos en el programa.
3. Tendrás que leer aproximadamente la mitad de los métodos de un control en un lugar de la documentación, y la otra mitad en otro.
1. ¿Eso es todo? ¿Para meterse con el punto 2, el vertido de métodos?
Alternativas:
1) La necesidad de añadir manualmente una llamada Event() para cada clase (que consiste en copiar con el ratón una línea y cambiar unas letras a la izquierda del punto) y, al mismo tiempo, en la lista de métodos de cada clase sólo tenemos métodos de trabajo correspondientes a esta clase, hizo clic en el punto, la lista se cayó y todo está claro.
2) Procesamiento automático de Event() de todas las clases, mientras que una función todavía tendrá que ser llamado desde OnChartEvent(), y por otro lado: un volcado de los métodos en la lista. Además, tendremos que destruir punteros en el deinit.
Mira un poco más profundo y más allá, por qué todos los Event() deben ser procesados en un bucle, cada control debe tener sus propias acciones para su Event(), los controles no son sólo para introducir un valor y no sólo para hacer que todo se mueva y parpadee en la pantalla, sino también (en la medida principal) para utilizar los valores introducidos en el programa.
3. Tendrás que leer aproximadamente la mitad de los métodos de un control en un lugar de la documentación, y la otra mitad en otro.
Lo has hecho todo bien.
Dadas las posibilidades de ME es bastante conveniente, el minimalismo japonés en la era del kitsch total, todo está ahí, nada superfluo.
Aquellos que quieran hacer un bucle a través de objetos pueden implementar un shell postfix donde pueden escribir lo que quieran.
- 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 Controles gráficos personalizados. Parte 3. Formularios:
Este es el último de los tres artículos dedicados a los controles gráficos. En él vamos a ver la creación del principal componente de la interfaz gráfica, el formulario, y su uso en combinación con otros controles. Además de las clases para formularios, las clases CFrame, CButton y CLabel se han añadido a la librería del control.
Autor: Dmitry Fedoseev