Discusión sobre el artículo "Interfaces gráficas X: Gestión ampliada de las listas y tablas. Optimización de código (build 7)"
Artículo publicado Interfaces gráficas X: Gestión avanzada de listas y tablas. Optimización del código (compilación 7):
Autor: Anatoli Kazharski
A que acceder para hacer lo mismo con la lista combobox, no funciona asi:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
Que acceder para hacer lo mismo con la lista de combo box, no funciona así:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
La clase CComboBox tiene métodos que devuelven punteros a la lista y a la barra de desplazamiento. Obteniendo punteros a estos elementos puedes llamar a sus métodos.
CListView *GetListViewPointer(void) { return(::GetPointer(m_listview)); }
CScrollV *GetScrollVPointer(void) { return(m_listview.GetScrollVPointer()); }
1. El estilo cebra se establecerá ahora por defecto para todas las tablas, ¿o lo he entendido mal?
1. El estilo cebra es un modo habilitado. Está desactivado por defecto. Si lo necesitas, basta con llamar al método correspondiente, especificando el segundo color. De hecho, en el artículo se explica con detalle.
2. Será posible.
3. Pensaré en ello como parte de la optimización posterior del código.
1. Modo habilitado para el estilo Zebra. Desactivado por defecto. Si lo necesita, basta con llamar al método correspondiente, especificando el segundo color. De hecho, en el artículo se habla de ello en detalle.
2. Será posible.
3. Pensaré en ello como parte de una mayor optimización del código.
3. Para ser sincero, me sorprende un poco la presencia de métodos repetitivos en su programa. Ojalá lo hubiera estudiado con más detenimiento... Puedes considerar mi código un "montón sin optimizar", pero no tengo ningún mecanismo que se repita dos veces. No hay funciones similares. Me gustaría que hicieras lo mismo. )
Hoy en día, cuando los elementos se componen en su mayoría de varios objetos gráficos, no se puede prescindir de métodos virtuales comunes. Por optimización en esta parte me refería a la fase de desarrollo en la que se dibujarán todos los elementos. Entonces, supongo, estos métodos virtuales estándar podrán reducirse a una única declaración e implementación en la clase base de un elemento.
No quiero discutir tu código aquí en absoluto. Es privado, así que guárdatelo para ti. Mi opinión sobre lo que he visto en tu código no ha cambiado.
1. En la actualidad, cuando los elementos se ensamblan en su mayoría a partir de varios objetos gráficos, es imposible prescindir de métodos virtuales comunes. Por optimización en esta parte me refería a la fase de desarrollo en la que se dibujarán todos los elementos. Entonces, supongo, estos métodos virtuales estándar podrán reducirse a una única declaración e implementación en la clase base de un elemento.
2. No quiero discutir tu código aquí en absoluto. Es privado, así que guárdatelo para ti. Mi opinión sobre lo que he visto en tu código no ha cambiado.
1. Quizás, cuando empieces a implementar la tecnología de los controles "dibujados", consigas deshacerte de la duplicación de métodos. Sin embargo, como usted mismo ha notado - usted asume que ayudará. Es decir, quizás no... Mi opinión es que estas cosas no están relacionadas.
Un elemento de control "dibujado" no es funcionalmente diferente de un elemento construido a partir de varios objetos, pero su creación requiere una tecnología completamente diferente. Es decir, una tecnología diferente de la que se utiliza para crear elementos formados por varios objetos.
Es interesante que el elemento dibujado conste de varios objetos, pero estos objetos, - por un lado no son objetos MT (sino sólo detalles de dibujo), y por otro lado - dentro del programa los detalles de dibujo son los mismos objetos funcionales con sus propias propiedades.
Es decir, el número de objetos no disminuye. A partir de los objetos MT, los detalles de los elementos (y los elementos mismos) se convierten en objetos internos del programa. Y el programa (a diferencia de la función OnChartEvent()) los ve, define y trabaja con ellos.
La tecnología es muy compleja y requiere una optimización muy alta del código...
2. Al no tener ni idea de cómo funciona todo el mecanismo, te has apresurado a dar tu opinión. No podrías cambiarlo porque hasta ahora has visto una mínima parte del código. Bueno, tendré que aguantar semejante opinión tuya. Ay).
P.D No discutamos. No me ofendo. :)
1. Tal vez, cuando se implementa la tecnología de controles "dibujado", usted será capaz de deshacerse de la duplicación de métodos. Sin embargo, como usted mismo ha notado - usted asume que ayudará. Es decir - tal vez no lo hará ... Mi opinión es que estas cosas no están relacionadas.
Lo asumo, ya que no lo he implementado y probado todavía.
Un elemento de control "dibujado" no es funcionalmente diferente de un elemento construido a partir de varios objetos, pero su creación requiere una tecnología completamente diferente. Es decir, una tecnología distinta de la que se utiliza para crear elementos formados por varios objetos.
Es interesante que el elemento dibujado conste de varios objetos, pero estos objetos, - por un lado no son objetos MT (sino sólo detalles de dibujo), y por otro lado - dentro del programa los detalles de dibujo son los mismos objetos funcionales con sus propias propiedades.
Es decir, el número de objetos no disminuye. A partir de los objetos MT, los detalles de los elementos (y los elementos mismos) se convierten en objetos internos del programa. Y el programa (a diferencia de la función OnChartEvent()) los ve, los define y trabaja con ellos.
Escribes cosas tan obvias que ni siquiera es interesante discutirlo contigo. Yo lo veo un poco diferente. Expresaré mi opinión en uno de los próximos artículos de la segunda etapa de desarrollo de la biblioteca.
Lo asumo, ya que aún no lo he implementado ni probado.
Escribes cosas tan obvias que ni siquiera es interesante discutirlo contigo. Yo lo veo un poco diferente. Expresaré mi opinión en uno de los próximos artículos de la segunda etapa de desarrollo de la biblioteca.
No sé por qué estas cosas son obvias para ti. ¿Ya lo has puesto en práctica?
La tecnología de la que hablamos no está descrita en ningún artículo de MQL. ¿O me equivoco y puedes darme un enlace?
Lo principal es que es imposible llegar a esta tecnología mediante una optimización cosmética - hay que"cambiar los cimientos".
Cambiar los cimientos es el proceso más difícil. Por lo general, todo se derrumba, - esquemas, interconexiones, mecanismos.... TODO. Entonces todo se restaura de nuevo.
Y al final, el código será bastante diferente de lo que era al principio.
H.Y. Imagina que alguien te dice después de todos tus esfuerzos: "Tu código es un montón sin optimizar". ¿Te ofenderías? :)
No sé por qué estas cosas son obvias para ti. ¿Ya lo has implementado?
La tecnología de la que hablamos no está descrita en ningún artículo de MQL. ¿O me equivoco y puedes darme un enlace?
Si no he implementado algo todavía, no significa que no haya pensado en ello y no sepa cómo lo implementaré. Simplemente aún no lo he puesto en práctica. A diferencia de ti, yo describo todo lo que hago con detalle. También me lleva tiempo.
No tengo que leer artículos para poner algo en práctica. Si no hay una solución ya hecha, busco mis propios métodos. Pero tú tienes la oportunidad de leer artículos. Y en lugar de leer y no hacer preguntas que se explican en el artículo, sigues "disparando" al azar.
Lo principal es que es imposible llegar a esta tecnología a través de una optimización cosmética - necesitas"cambiar los cimientos".
Cambiar los cimientos es el proceso más difícil. Normalmente todo se derrumba - esquemas, interconexiones, mecanismos.... TODO.
Y al final, el código será muy diferente de lo que era al principio.
Con la programación orientada a objetos es diferente. Usted acaba de tener una brecha absoluta en esta esfera del conocimiento. Lo que para ti es "el proceso más difícil" se puede resolver simplemente con la programación orientada a objetos.
H.I. Imagina que alguien te dice después de todos tus esfuerzos: "Tu código es un montón sin optimizar". ¿Te ofenderías? :)
La ofensa no es propia de mí. Recuerdo que uno de los participantes del foro inglés sugirió una solución (sin implementación) de cómo mejorar el esquema. La utilicé. El proceso más difícil no surgió. Con tu planteamiento te torturarás durante mucho tiempo presumiendo de mala implementación y peleándote con molinos de viento.
- 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 Interfaces gráficas X: Gestión ampliada de las listas y tablas. Optimización de código (build 7):
Es necesario optimizar el código de la librería: debe estar mejor ordenado, o sea, ser más comprensible y legible. Además de eso, vamos a continuar el desarrollo de los controles creados anteriormente: listas, tablas y barras de desplazamiento.
Por eso, se ha decidido crear una clase intermedia adicional heredada, en la que se puede colocar el código repetido con frecuencia y los métodos para el trabajo con el puntero al formulario al que se adjuntan los controles. Es una parte del esquema de la librería en cuanto a las interacciones entre el formulario y los controles:
Fig. 3. Parte del esquema de la librería en cuanto a las interacciones entre el formulario y los controles
Autor: Anatoli Kazharski