Discusión sobre el artículo "Interfaces gráficas I: Preparación de la estructura de la biblioteca (Capítulo 1)" - página 3
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
...Pero desde el punto de vista de la programación orientada a objetos, el método propuesto es el que tiene más posibilidades de aplicación práctica. :)
Es más fácil decirlo que hacerlo.
...
Consideremos, por ejemplo, la función de mover una forma en el gráfico.
En la función necesitamos enumerar todos los objetos creados de la forma. ¿Por qué? Porque todos los elementos creados se colocan en el contenedor (array) del propio formulario. ¿Por qué es necesario enumerar todos los elementos creados en la función? ¿Por qué no puedes simplemente hacer un bucle alrededor del contenedor y cambiar las coordenadas de todos los elementos?
...
Presta atención al tipo(CChartObject) del array(m_objects), que almacena punteros de todos los objetos gráficos de tal o cual elemento(CElement). Puedes intentar usar la conversión dinámica de tipos en este caso, pero entonces el código se volverá aún más complicado y voraz en términos de consumo de recursos, porque tendrás que hacer comprobaciones adicionales para el tipo de puntero.
En cuanto a Delete() y métodos similares, puedes hacer un bucle a través de ellos (sólo que aún no he llegado a ello), ya que todos los objetos tienen tipo CChartObject.
Asumo con cautela que todo será mucho más fácil después de la transición a la segunda etapa de desarrollo de la biblioteca, cuando todos los elementos serán dibujados. Es decir, habrá un elemento - un objeto(bmp).
comprobaciones adicionales sobre el tipo de puntero.
¿Y cómo hacer una comprobación del tipo de puntero en MQL?
Según mis datos, el lenguaje no tiene ningún medio para esto. Me gustaría comprobar si un objeto es una instancia de una clase en particular o si es descendiente de una clase en la jerarquía.
Por ejemplo, estoy implementando un patrón MVC y para ciertos modelos con propiedades editables (que tienen un ancestro común) suscribo un objeto vista. Con el fin de mostrar la tabla de propiedades de este objeto. Después de cambios en el modelo, el listener (vista) se redibuja y se pasa el objeto modelo.
Aquí tenemos que convertir el modelo a uno de los tipos de la jerarquía de modelos (que pueden devolver propiedades). Pero es imposible comprobar que ha llegado un objeto del tipo correcto.
Teóricamente, un programador externo que cree una aplicación para una interfaz puede cometer un error y firmar esta vista a otro modelo (de otra jerarquía, que no tenga un ancestro con propiedades editables). Esto no se puede manejar en tiempo de ejecución y la aplicación se bloqueará.
Asumo con cautela que todo será mucho más fácil después de la transición a la segunda etapa de desarrollo de la biblioteca, cuando todos los elementos serán dibujados. Es decir, habrá un elemento - un objeto(bmp).
Yo seguí este camino hace un par de años. Primero hice un modelo DOM para la interfaz, dibujando primitivas, agregando vistas, pasando eventos (popup, stop). Todo se dibujaba sobre objetos gráficos MQL y en principio funcionaba. Pero cuando el número de objetos superaba los 200, empezaba a ralentizarse debido a la sobrecarga de redibujar cada objeto. Por eso se abandonó todo un año más hasta que apareció Canvas. Entonces todo se transfirió rápidamente a él sustituyendo los métodos básicos de dibujo de la vista y la lógica de actualización sin cambiar nada más. Y ahora incluso varios miles de vistas en la pantalla no conducen a un retraso en el dibujo, porque todo se dibuja y se compara muy rápidamente en la memoria, y la salida es sólo una imagen, es decir, sólo 1 elemento de los objetos en el gráfico.
Sin embargo, durante el último año, por falta de tiempo libre, el desarrollo de la biblioteca de interfaz de usuario prácticamente se ha detenido.
Para no ser insustancial, pondré un ejemplo de una interfaz construida en base a UI sobre un único elemento Canvas
Para no ser insustancial voy a poner un ejemplo de una interfaz construida en base a UI sobre un elemento Canvas
¿Cómo puedo comprobar el tipo de puntero en MQL?
Según mis datos, el lenguaje no tiene ningún medio para esto. Me gustaría comprobar si un objeto es una instancia de una clase en particular o si es descendiente de una clase en la jerarquía.
Por ejemplo, estoy implementando un patrón MVC y para ciertos modelos con propiedades editables (que tienen un ancestro común) suscribo un objeto vista. Con el fin de mostrar la tabla de propiedades de este objeto. Después de cambios en el modelo, el listener (vista) se redibuja y se pasa el objeto modelo.
Aquí tenemos que convertir el modelo a uno de los tipos de la jerarquía de modelos (que pueden devolver propiedades). Pero es imposible comprobar que ha llegado un objeto del tipo correcto.
Teóricamente, un programador externo que cree una aplicación para una interfaz puede cometer un error y firmar esta vista a otro modelo (de otra jerarquía, que no tenga un ancestro con propiedades editables). Esto no se puede manejar en tiempo de ejecución y la aplicación se bloqueará.
...
¿Quizás mediante dynamic_cast? Cuando empecé a desarrollar la librería, dynamic_cast aún no estaba disponible.
Algo así (ejemplo de aquí) :
class CBar { };
//+------------------------------------------------------------------+
//| Función de inicio del programa de script|
//+------------------------------------------------------------------+
void OnStart()
{
void *vptr[2];
vptr[0]=new CFoo();
vptr[1]=new CBar();
//---
for(int i=0;i<ArraySize(vptr);i++)
{
if(dynamic_cast<CFoo *>(vptr[i])!=NULL)
Print("CFoo * object at index ",i);
if(dynamic_cast<CBar *>(vptr[i])!=NULL)
Print("CBar * object at index ",i);
}
CFoo *fptr=vptr[1]; // error de conversión de puntero, vptr[1] no es un objeto CFoo
}
//+------------------------------------------------------------------+
//---
Seguí este camino hace un par de años. Primero hice un modelo DOM para la interfaz, dibujando primitivas, agregando vistas, pasando eventos (popup, stop). Todo se dibujaba sobre objetos gráficos MQL y en principio funcionaba. Pero cuando el número de objetos superaba los 200, empezaba a ralentizarse debido a la sobrecarga de redibujar cada objeto. Por eso se abandonó todo un año más hasta que apareció Canvas. Entonces todo se transfirió rápidamente a él sustituyendo los métodos básicos de dibujo de la vista y la lógica de actualización sin cambiar nada más. Y ahora incluso varios miles de vistas en la pantalla no conducen a un retraso en el dibujo, porque todo se dibuja y compara muy rápidamente en la memoria, y la salida es sólo una imagen, es decir, sólo 1 elemento de los objetos en el gráfico.
Es cierto que desde hace un año, por falta de tiempo libre, el desarrollo de la librería UI está prácticamente parado.
Esto es muy interesante. ¿ Has implementado también tus propios campos de entrada ?
Para no ser insustancial, voy a dar un ejemplo de una interfaz construida sobre la base de UI en un elemento Bitmap
Tiene buena pinta. Gracias por el ejemplo. )
Había un tema en el que tus recomendaciones serían muy útiles: Hacer un proyecto crowdsource sobre Canvas
¿Quizás mediante dynamic_cast? Cuando empecé a desarrollar la biblioteca dynamic_cast aún no estaba disponible.
Oh, no lo había visto. Oh, gracias. Resulta que lo añadieron en agosto. Si devuelve NULL y no se produce ningún error crítico, ya está muy bien. Podemos trabajar )
¿Has implementado también tus propios campos de entrada?
Con los campos de entrada se hace así
en el evento focus en el objeto del campo editable, un objeto gráfico del campo editable de la configuración requerida con el valor actual se inserta en la UI, con el que se puede trabajar, utilizando también el buffer de entrada (no hay manera sin él en la interfaz),
en el evento de desenfoque se guarda el valor del campo (y se borra el objeto gráfico del sistema - Editar). Y el valor se muestra en el bmp con texto.
Igor Volodin:
...
Con los campos de entrada se hace de la siguiente manera:
en el evento focus sobre el objeto del campo editable, se inserta en la UI un objeto gráfico del campo editable de la configuración requerida con el valor actual, con el que se puede trabajar utilizando, entre otras cosas, el buffer de entrada (no hay forma de trabajar sin él en la interfaz),
en el evento blur se guarda el valor del campo (y se borra el objeto gráfico del sistema - Editar). Y el valor se muestra en el bmp como texto.
Aha, lo tengo. Gracias por la aclaración.
Creo que esta es la mejor opción, pero quiero intentar realizarlo todo de forma que todo se dibuje en un solo objeto. Permitiría obtener plena independencia y experiencia cuando no importa en qué entorno se crea una GUI. Digamos que sólo hay un lienzo y nada más. )
Tiene buena pinta. Gracias por el ejemplo. )
Había un tema aquí donde tus recomendaciones vendrían bien: Hacer un proyecto de Canvas crowdsourced.
Gracias. Mirando a la cantidad de trabajo en la interfaz, un gran aplauso para usted. Yo no habría sido capaz de hacerlo. En primer lugar la publicidad, en segundo lugar la coherencia.
¿Con financiación pública? Es arriesgado. Por supuesto, si tienes ingresos estables y tiempo libre, es posible trabajar en beneficio de la sociedad. Pero la sociedad MQL la utilizará para productos comerciales, no gratuitos. Y la licencia GPL por sí sola no lo prohibirá.
En resumen, no veo ningún beneficio para mí.
Pero con el tiempo me gustaría intentar realizar todo de tal manera que todo se dibuje en un solo objeto. Permitiría obtener plena independencia y experiencia cuando no importa en qué entorno crees una interfaz gráfica. Digamos que sólo hay un lienzo y nada más. )