Realización de un proyecto crowdsourced en Canvas - página 36
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
Cualquier elemento de un diálogo (formulario, control (botón, lista, imagen)) tiene algunas propiedades. La programación procedimental no define el concepto de "propiedad" o "campo". En la programación procedimental, tenemos funciones y variables (globales o locales). Pero las variables son comunes a, por lo que no pueden utilizarse para describir las propiedades de cada control individual. Entonces, ¿cuál es la solución? Una simple: ¡estructuras!
Sí, una estructura puede tener una descripción de las propiedades necesarias de un control, así como una matriz de controles anidados (hasta el infinito).
Todo esto se almacena en una matriz de cuadros de diálogo.
Podemos hacerlo más universal: la estructura de descripción del control consta de dos matrices: matriz de propiedades y matriz de elementos esclavos. Un array de propiedades es un array de estructuras de un par propiedad-valor. Con este enfoque, cada nuevo control puede tener cualquier conjunto arbitrario de propiedades. Pero esto no es conveniente para el procesamiento. Sería más lógico especificar las propiedades específicas del control en la estructura: dimensiones, ubicación, color, marco, etc., todo lo que necesita cualquier control.
Y la estructura también contendrá una matriz de píxeles del control.
Cuando se recibe un evento del ratón, todas las matrices se repiten para comprobar si el cursor llega a un control concreto. El control se realiza desde el último hasta el primer control.
Una vez que se determina cuál es el control que tiene el cursor, se envía el elemento del array dado a la función de repintado y entonces se actualiza el array de recursos y la imagen en el gráfico.
No sé lo que ha publicado y lo que ha hecho en materia de GUI, pero en mis hilos no ha hecho ninguna sugerencia técnica, ninguna solución y ninguna discusión sobre el tema. Sólo trolling vacío, señalando soluciones de terceros e instando a no reinventar la rueda.
Volviendo al tema que nos ocupa.
Por lo que conozco de la biblioteca estándar (muy poco en realidad), allí los elementos y las ventanas se componen de objetos MT. Es decir, en nuestro contexto, no se dibujan en el lienzo. Por supuesto que se dibujan, pero no en nuestro lienzo, lo que nos impide controlar los colores de los píxeles, crear gradientes de superficie y mucho más.
En teoría, podríamos tomar la estructura de la biblioteca, copiarla y hacer un análogo en el kanvas. En teoría...
El problema es que el propio CCanvas no es adecuado para hacer una GUI en él. ¿Por qué? Porque el sistema kanvas se utiliza principalmente para las primitivas gráficas. Así que, en esencia, esta clase no proporciona nada más que primitivas. El arquetipo de GUI debe ser construido por usted mismo. Y en este caso, la clase no es necesaria. Es más conveniente arreglárselas con sus propias soluciones. Después de todo, se puede dibujar un marcador rectangular sin la clase. Al igual que se puede crear o cargar un lienzo. Es muy sencillo. Por lo tanto, he preferido mi propia solución.
Pero alguien no puede prescindir de CCanvas. Por eso no insisto en ello.
El problema de CCanvas es que su interfaz gráfica está estrictamente ligada a la ventana del gráfico.
Es decir, no se puede hacer una ventana completa como módulo de interfaz de terminal.
Y sería muy bueno escribir tus propios módulos de interfaz.
ligeramente equivocado, por supuesto :-)
He publicado una interfaz para la DLL Tcl (que es el lenguaje común de las herramientas), que tiene gráficos Tk que se comparten como una interfaz gráfica de usuario en Python/Ruby/etc.
el objetivo no era conseguir una GUI, sino un bonito subproducto :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
en mi opinión conveniente y sobre todo corto :-)
No estoy agitando a nadie - conozco tcl/tk, lo uso, comparto mi experiencia (ver sourceforge atcl)
Sí Max, eso es exactamente lo que estoy hablando de TCL y su prototipo que estábamos discutiendo en ese momento. La limitación era que el usuario tenía que tener instalada la biblioteca correspondiente en su ordenador. No parecía difícil, pero sigue siendo una cierta limitación.
Dejemos eso en el pasado. Max, únete a la discusión. Roman, únete también ))).
De lo anterior se puede entender que un elemento de estructura es un control de diálogo específico, contiene sus propias propiedades y puede contener controles anidados. El conjunto de propiedades de un control universal de este tipo sólo está limitado por la imaginación del desarrollador.
Por supuesto, podemos evitar la estructura y describir las propiedades de los controles en un array multidimensional, pero no es inicialmente rentable porque necesitamos recordar claramente qué índice del control almacena cada propiedad. Y el array no puede contener tipos de datos heterogéneos. Resulta que la descripción del elemento de control en la programación procedimental sólo es posible a través de las estructuras. Es decir, el elemento de estructura es un control concreto, es decir, el objeto concreto del diálogo con sus propiedades.
El problema de CCanvas es que su interfaz gráfica está estrictamente ligada a la ventana del gráfico.
Es decir, no se puede hacer una ventana completa como módulo de interfaz de terminal.
Y sería muy bueno escribir tus propios módulos de interfaz.
Luego vendrá lo contrario: vincular la interfaz con el gráfico. Por ejemplo, haga un botón que esté estrictamente vinculado a la hora y al precio.
Se puede escribir una interfaz gráfica de usuario independiente en muy poco tiempo, con todas las tablas, pestañas, menús y silbatos. En C# o incluso en BASIC. Y dentro de la carta es un problema importante para las aplicaciones externas.
Cualquier elemento de un diálogo (formulario, control (botón, lista, imagen)) tiene algunas propiedades. La programación procedimental no define el concepto de "propiedad" o "campo". En la programación procedimental, tenemos funciones y variables (globales o locales). Pero las variables son comunes a, por lo que no pueden utilizarse para describir las propiedades de cada control individual. Entonces, ¿cuál es la solución? Una simple: ¡estructuras!
Sí, una estructura puede tener una descripción de las propiedades necesarias de un control, así como una matriz de controles anidados (hasta el infinito).
Todo esto se almacena en una matriz de cuadros de diálogo.
Podemos hacerlo más universal: la estructura de descripción del control consta de dos matrices: matriz de propiedades y matriz de elementos esclavos. Un array de propiedades es un array de estructuras de un par propiedad-valor. Con este enfoque, cada nuevo control puede tener cualquier conjunto arbitrario de propiedades. Pero esto no es conveniente para el procesamiento. Sería más lógico especificar las propiedades específicas del control en la estructura: dimensiones, ubicación, color, marco, etc., todo lo que necesita cualquier control.
Y la estructura también contendrá una matriz de píxeles del control.
Cuando se recibe un evento del ratón, todas las matrices se repiten para comprobar si el cursor llega a un control concreto. La comprobación se realiza desde el último control hasta el primero.
Una vez que se determina cuál es el control que tiene el cursor, entonces el elemento del array se envía a la función de repintado y entonces se actualiza el array de recursos y se actualiza la imagen en el gráfico.
1. Suponga que ha diseñado una estructura sencilla de controles básicos: una ventana, un botón, una casilla de verificación. Cada uno de ellos está formado por un conjunto de componentes - objetos. Casilla de verificación - base, texto, icono. Botón - base, texto, icono, etc. Cada objeto de cada elemento debe tener su propio conjunto de propiedades. Se pueden escribir en una estructura o clase, pero en mi opinión, no es conveniente. ¿Por qué? - Porque cuando los pones en una ventana, necesitas encontrarlos en el lienzo con el cursor. Cuando mueves el cursor, tienen que enfocarse. Para ello, sus coordenadas actuales deben estar en un array. Y es más conveniente si todas sus propiedades (incluyendo las coordenadas actuales) están en el mismo array. De este modo, puedes acceder inmediatamente a cualquier propiedad de cualquier elemento del lienzo que sea el foco del cursor. También es más fácil recorrer un array de elementos.
Es decir, es más fácil recorrer UN array en un bucle para encontrar el elemento que el cursor ha golpeado. Es aún más conveniente si esta matriz es global. Entonces, en cualquier función, puedes tomar la información necesaria de ella y cambiar los valores de las propiedades necesarias, de los elementos necesarios.
Este es el acceso más corto y eficiente a los elementos y su procesamiento más rápido. Este es mi "núcleo".
2. Sin embargo, conociendo los caprichos de los profesionales de esforzarse por imitar al máximo la POO estándar, no propongo esta tecnología.
3. un array de píxeles no necesita ser almacenado en ningún sitio. Se construye en el momento de la necesidad, según los parámetros de los elementos del array. Por ejemplo: hay que redibujar la ventana. Llamamos a la función repaint. La función llama al array de elementos, ve todas sus propiedades, declara el array de píxeles, calcula su tamaño, dibuja sus objetos sucesivamente en el bucle, llama a ResourceCreate(). Eso es todo.
Un elemento atrapado bajo el cursor es enviado a la misma función para ser repintado. Recibe una notificación (bandera de repintado) y su número en el array de elementos. A continuación, la función llama al recurso requerido a través de ResourceReadImage(), lo pone en la matriz de píxeles y luego, dentro de la matriz de píxeles, encuentra el área del elemento requerido y repinta todos sus objetos. Eso es todo.
1. Suponga que ha diseñado una estructura sencilla de controles básicos: una ventana, un botón, una casilla de verificación. Cada uno de ellos está formado por un conjunto de partes constitutivas: los objetos. Casilla de verificación - base, texto, icono. Botón - base, texto, icono, etc. Cada objeto de cada elemento debe tener su propio conjunto de propiedades. Se pueden escribir en una estructura o clase, pero en mi opinión, no es conveniente. ¿Por qué? - Porque cuando los pones en una ventana, necesitas encontrarlos en el lienzo con el cursor. Cuando mueves el cursor, tienen que enfocarse. Para ello, sus coordenadas actuales tienen que estar en un array. Y es más conveniente si todas sus propiedades (incluyendo las coordenadas actuales) están en el mismo array. De este modo, puedes acceder inmediatamente a cualquier propiedad de cualquier elemento del lienzo que sea el foco del cursor. También es más fácil recorrer un array de elementos.
Es decir, es más fácil recorrer UN array en un bucle para encontrar el elemento que el cursor ha golpeado. Es aún más conveniente si esta matriz es global. Entonces, en cualquier función, puedes tomar la información necesaria de ella y cambiar los valores de las propiedades necesarias, de los elementos necesarios.
Este es el acceso más corto y eficiente a los elementos y su procesamiento más rápido. Este es mi "núcleo".
2. Sin embargo, conociendo los caprichos de los profesionales de esforzarse por imitar al máximo la POO estándar, no propongo esta tecnología.
3. un array de píxeles no necesita ser almacenado en ningún sitio. Se construye en el momento de la necesidad, según los parámetros de los elementos del array. Por ejemplo: hay que redibujar la ventana. Llamamos a la función repaint. La función llama al array de elementos, ve todas sus propiedades, declara el array de píxeles, calcula su tamaño, dibuja sus objetos sucesivamente en el bucle, llama a ResourceCreate(). Eso es todo.
Un elemento atrapado bajo el cursor es enviado a la misma función para ser redibujado. Recibe una notificación (bandera de repintado) y su número en la matriz de elementos. A continuación, la función llama al recurso requerido a través de ResourceReadImage(), lo pone en la matriz de píxeles y luego, dentro de la matriz de píxeles, encuentra el área del elemento requerido y repinta todos sus objetos. Eso es todo.
En realidad, esto debería funcionar independientemente de la tecnología de construcción. Pero se puede percibir de otra manera. En tu caso, pasas un array en el bucle y determinas qué control tiene el cursor en ese momento. Así, cuando se define el índice se ven inmediatamente las propiedades del elemento encontrado. Pero, ¿cómo se pueden almacenar diferentes tipos de datos en una gran matriz?
En realidad, esto debería ocurrir independientemente de la tecnología de construcción. Sólo se puede percibir de diferentes maneras. En tu caso, recorres el array y determinas qué control tiene el cursor en ese momento. Así, cuando se define el índice se ven inmediatamente las propiedades del elemento encontrado. Pero, ¿cómo se pueden almacenar diferentes tipos de datos en una gran matriz?
En principio, es posible generalizar los tipos. He llegado a la conclusión de que no pasará nada malo, si la gran mayoría de las propiedades de los objetos son de tipo int. Todos los demás (el doble está prácticamente ausente en las propiedades de los objetos gráficos) tipos abreviados los he obviado en aras de la simplificación. El "exceso" de memoria es tan insignificante que no tiene sentido pensar en ello. Por supuesto, no podemos ir por tal sacrilegio en aras de la profesionalidad)). Pero estamos en el siglo XXI y no me amenazan las hogueras).
Hice los nombres de los objetos como números, y los puse en la serie general de propiedades de los objetos.
El único lugar donde necesitaba un tipo de datos diferente era en los parámetros de control. Allí creé un segundo núcleo, que almacena las propiedades de los parámetros, y los valores mismos en el tipo string, que puedo castear fácilmente a cualquier cosa (o más bien, a lo que se prescribe en las propiedades de los parámetros).
SUGERENCIA: Por "parámetro del elemento de control" se entiende el PARÁMETRO GESTIONADO POR EL EQUIPO.1. Suponga que ha diseñado una estructura sencilla de controles básicos: una ventana, un botón, una casilla de verificación. Cada uno de ellos está formado por un conjunto de partes constitutivas: los objetos. Casilla de verificación - base, texto, icono. Botón - base, texto, icono, etc. Cada objeto de cada elemento debe tener su propio conjunto de propiedades. Se pueden escribir en una estructura o clase, pero en mi opinión, no es conveniente. ¿Por qué? - Porque cuando los pones en una ventana, necesitas encontrarlos en el lienzo con el cursor. Cuando mueves el cursor, tienen que enfocarse. Para ello, sus coordenadas actuales deben estar en un array. Y es más conveniente si todas sus propiedades (incluyendo las coordenadas actuales) están en el mismo array. De este modo, puedes acceder inmediatamente a cualquier propiedad de cualquier elemento del lienzo que sea el foco del cursor. También es más fácil recorrer un array de elementos.
Es decir, es más fácil recorrer UN array en un bucle para encontrar el elemento que el cursor ha golpeado. Es aún más conveniente si esta matriz es global. Entonces, en cualquier función, puedes tomar la información necesaria de ella y cambiar los valores de las propiedades necesarias, de los elementos necesarios.
Este es el acceso más corto y eficiente a los elementos y su procesamiento más rápido. Este es mi "núcleo".
2. Sin embargo, conociendo los caprichos de los profesionales de esforzarse por imitar al máximo la POO estándar, no propongo esta tecnología.
3. un array de píxeles no necesita ser almacenado en ningún sitio. Se construye en el momento de la necesidad, según los parámetros de los elementos del array. Por ejemplo: hay que redibujar la ventana. Llamamos a la función repaint. La función llama al array de elementos, ve todas sus propiedades, declara el array de píxeles, calcula su tamaño, dibuja sus objetos sucesivamente en el bucle, llama a ResourceCreate(). Eso es todo.
Un elemento atrapado bajo el cursor es enviado a la misma función para ser repintado. Recibe una notificación (bandera de repintado) y su número en la matriz de elementos. A continuación, la función llama al recurso requerido a través de ResourceReadImage(), lo pone en la matriz de píxeles, y además, dentro de la matriz de píxeles, encuentra el área del elemento requerido y repinta todos sus objetos. Eso es todo.
ugh esta eterna negatividad a oop, justo en la línea
¿Se ha preguntado alguna vez cómo surgió? La cuestión es que muchas personas que escriben en estilo procedimental y no conocen la POO se enfrentan al deseo de agrupar funciones, y luego este deseo se convierte en un deseo de combinar estas funciones en una zona de memoria y referirse a ella, es decir, referirse físicamente a la zona con funciones que se almacena en una variable. Entonces queremos cambiar nuestro grupo de funciones seleccionadas sin duplicar el código (obtenemos la herencia). Así, una persona que inicialmente sólo está familiarizada con el estilo procedimental, algún tiempo después pregunta por qué hay tantas restricciones en un mql (referencia a la herencia múltiple).
En general, se cree que es más fácil enseñar OOP de una vez, porque si una persona está familiarizada con el estilo procedimental, será muy difícil volver a entrenar después (para la mayoría de la gente), pero hay otros, ya que inicialmente sólo había estilo procedimental... descrito anteriormente.
ZS Hay una variación en la POO en general, un poco familiarizada con la POO a nivel de código procedimental, y realmente utilizando la POO al máximo.
Una clase es una referencia a una memoria (tabla) de funciones, que puede reescribirse y ampliarse manteniendo la matriz principal + la referencia a las variables. y se me olvida qué más.... (como 32 bytes)
Con el problema de la búsqueda eterna, recientemente he comparado la función de ordenación incorporada con la ordenación roja (una de las plantillas de ordenación), la pérdida de velocidad por 3-6 veces en ciertas condiciones (incorporada perdió =)
En cuanto a la interfaz gráfica, creo que hay métodos estándar.
,
Uf, esta negatividad perpetua hacia la OOP, a través de las líneas.
¿Se ha preguntado alguna vez cómo surgió? El asunto es que muchas personas que escriben en estilo procedimental y sin saber de OOP se enfrentan al deseo de agrupar funciones, luego este deseo crece en un deseo de combinar estas funciones en un área de memoria y referirse a ella, es decir, referirse físicamente a un área con funciones que se almacena en una variable. Entonces queremos cambiar nuestro grupo de funciones seleccionadas sin duplicar el código (obtenemos la herencia). Así, una persona que inicialmente sólo está familiarizada con el estilo procedimental, algún tiempo después pregunta por qué hay tantas restricciones en un mql (referencia a la herencia múltiple).
En general, se cree que es más fácil enseñar OOP de una vez, porque si una persona se familiariza con el estilo procedimental entonces será muy difícil volver a entrenar (para la mayoría de la gente), pero hay otros, ya que inicialmente sólo había estilo procedimental... descrito anteriormente.
ZS Hay una variación en la POO en general, un poco familiarizada con la POO a nivel de código procedimental, y realmente utilizando la POO al máximo.
Una clase es una referencia a una memoria (tabla) de funciones, que puede reescribirse y ampliarse manteniendo la matriz principal + la referencia a las variables. y se me olvida qué más.... (como 32 bytes)
Con el problema de la búsqueda eterna, recientemente he comparado la función de ordenación incorporada con la ordenación roja (una de las plantillas), la pérdida de velocidad por 3-6 veces en ciertas condiciones (incorporado perdido =)
En cuanto a la interfaz gráfica, creo que hay métodos estándar.
,
No tengo ninguna negatividad hacia el concepto de OOP. Yo mismo soy partidario de ello. Tengo una negativa a las normas. Para ser más precisos, a seguirlos sin pensar).
Aparte de eso, estoy a favor de OOP. Pero estoy a favor de la OOP simplificada.