Realización de un proyecto crowdsourced en Canvas - página 39
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
...
Peter, has hecho un gran trabajo al crear una biblioteca GUI en tu estilo. Pero si piensas publicarlo, vale la pena rediseñarlo a una tecnología diferente. Estoy dispuesto a ayudarte en esto y a transferir paso a paso todo el poder de tu biblioteca de una manera nueva.
Alexey, digamos que me gustaría probarlo. ¿Cómo propone hacerlo? Es un trabajo imposible.
Peter, probablemente no pueda imaginar ni siquiera una pequeña fracción de la cantidad de trabajo que has realizado, y estoy más que seguro de que simplemente subestimo la magnitud de los objetos creados. ¡PERO!
Como siempre, ¡hay un PERO!
Cualquier proyecto, ni siquiera necesariamente de programación.
Para empezar, nos abstraemos de los objetos que se han creado. Es decir, no los representaremos como una matriz, estructuras o clases. Simplemente aceptaremos la noción de OBJETO (alias elemento de control, alias formulario, alias interfaz en su conjunto, etc.). Trata de establecer la interacción de los objetos de forma estructural. Cuando descubramos juntos lo que se construye, intentaremos revelar las regularidades sobre esta base. En principio, no tendrá que identificarlos porque los identificó hace tiempo e hizo un tratamiento unificado para ellos, simplemente explicará el principio de funcionamiento y la finalidad. Entonces simplemente sustituiremos un objeto por otro en su proyecto. Por supuesto, será mucho más difícil que escribir desde cero. Pero en nuestro caso tenemos un objetivo ligeramente diferente, así que en general no hay prisa. Pero las publicaciones sobre la traducción del algoritmo de la matriz al algoritmo del objeto probablemente serían interesantes no sólo para los principiantes. Estoy convencido de que en el proceso de este trabajo otros participantes se unirán a nosotros y compartirán sus ideas o impulsarán una implementación más conveniente de tal o cual algoritmo.
De un modo u otro, la idea en sí debe representarse primero mediante un diagrama de flujo del algoritmo.
Hice mi sugerencia. Pero puedes hacer lo contrario, todo depende de tu deseo y visión del asunto (trabajo conjunto).
Peter, probablemente no puedo ni imaginar una pequeña fracción de la cantidad de trabajo que has realizado, y estoy más que seguro de que simplemente subestimo la magnitud de los objetos que has creado. ¡PERO!
Como siempre, ¡hay un PERO!
Cualquier proyecto, ni siquiera necesariamente de programación.
Para empezar, nos abstraemos de los objetos que se han creado. Es decir, no los representaremos como una matriz, estructuras o clases. Simplemente aceptaremos la noción de OBJETO (alias elemento de control, alias formulario, alias interfaz en su conjunto, etc.). Trata de establecer la interacción de los objetos estructuralmente. Cuando descubramos juntos lo que se construye, intentaremos revelar las regularidades sobre esta base. En principio, no tendrá que identificarlos porque los identificó hace tiempo e hizo un tratamiento unificado para ellos, simplemente explicará el principio de funcionamiento y la finalidad. Entonces simplemente sustituiremos un objeto por otro en su proyecto. Por supuesto, será mucho más difícil que escribir desde cero. Pero en nuestro caso tenemos un objetivo ligeramente diferente, así que en general no hay prisa. Pero las publicaciones sobre la traducción del algoritmo de la matriz al algoritmo del objeto podrían ser interesantes no sólo para los principiantes. Estoy convencido de que en el proceso de este trabajo otros participantes se unirán a nosotros y compartirán sus ideas o impulsarán una implementación más conveniente de tal o cual algoritmo.
De un modo u otro, la idea en sí debe representarse primero mediante un diagrama de flujo del algoritmo.
He hecho mi sugerencia. Pero se puede hacer otra cosa, todo depende de las ganas y de la visión que se tenga del asunto (trabajar juntos).
Muy bien. Haré lo que pueda. Explicaré las soluciones y la arquitectura. Pero no sé si al final lo conseguiré.
Ahora los objetos están dispuestos en el núcleo. Hay que sacarlos del núcleo y ponerlos en las clases.
1. Probablemente crearía tres clases básicas: "Rectangle_label", que albergaría todas las propiedades básicas de las etiquetas rectangulares, "Icon" y "Text". Estos objetos forman parte de casi todos los controles.
2. A continuación, cree un grupo de clases descendientes. Se dividirían por los siguientes criterios: a) elementos que controlan un parámetro. b) elementos que son controlados por el parámetro.
3. Las clases describirían las propiedades específicas de cada elemento.
Estas son sólo las primeras ideas. Pueden estar equivocados.
Con este esquema, la herencia se convierte inmediatamente en múltiple: las clases de elementos (herederos) deben incluir propiedades de tres clases base a la vez.
Muy bien. Haré lo que pueda. Explicaré las soluciones y la arquitectura. Pero no sé si al final tendré éxito.
Ahora mismo, los objetos están organizados en el núcleo. Hay que sacarlos del núcleo y ponerlos en las clases.
1. Probablemente crearía tres clases básicas: "Rectangle_label", que albergaría todas las propiedades básicas de las etiquetas rectangulares, "Icon" y "Text". Estos objetos forman parte de casi todos los controles.
2. A continuación, cree un grupo de clases descendientes. Se dividirían por los siguientes criterios: a) elementos que controlan un parámetro. b) elementos que son controlados por el parámetro.
3. Las clases describirían las propiedades específicas de cada elemento.
Estas son sólo las primeras ideas. Pueden estar equivocados.
Con este esquema, la herencia resulta ser plural a la vez - las clases de elementos (descendientes) deben incluir propiedades de tres clases básicas a la vez.
Así que aquí va un razonamiento.
"Crearía tres clases base: "Rectangle_label", que contendría todas las propiedades básicas de las etiquetas rectangulares, "Icon", y "Text". - Clásicamente, el primer objeto simplemente se llama Rectángulo o Rect, el segundo generalizado Imagen, bueno, el tercero puede ser descrito por propiedades separadas o también hacer un objeto separado. Para indicar que el tipo de datos creado es una clase en c++ y en mql es habitual indicar C antes del nombre del tipo, es decir, CRectangle, CImage, CText. Pero los tipos simples que sólo contienen datos heterogéneos son más convenientes de crear como estructuras.
Lo primero que hay que tener en cuenta son todas las propiedades básicas de los controles LARGE. Más adelante puedes añadir cualquier propiedad, no será un problema.
"a) elementos que controlan un parámetro. b) elementos que son controlados por un parámetro". - se requiere un desciframiento aquí. No entiendo qué significan estas descripciones.
"si habrá éxito al final" - todavía es mejor estar seguro de que habrá éxito. De lo contrario, es mejor no empezar.Bueno, aquí va un razonamiento.
1. "Crearía tres clases básicas: "Rectangle_label", que contendría todas las propiedades básicas de las etiquetas rectangulares, "Icon" y "Text". - Clásicamente, el primer objeto se llama simplemente Rectángulo o Rect, el segundo generalizado Imagen, así, el tercero puede ser descrito por propiedades separadas lobo también hacer un objeto blanco. Para indicar un tipo de datos creado como una clase en c++ y en mql, es habitual indicar C antes del nombre del tipo, es decir, CRectangle, CImage, CText
2. "a) elementos que controlan el parámetro. b) elementos que son controlados por el parámetro". - se requiere un desciframiento aquí. No entiendo qué significan estas descripciones.
"¿Habrá éxito al final?": aún es mejor estar seguro de que habrá éxito. De lo contrario, es mejor no empezar.1. La clase más básica es GHObjest (objeto gráfico básico). Debe haber propiedades x,y, x_size, y_sixe y diferentes tipos de unión de coordenadas. Son propiedades comunes a TODOS los objetos.
2. sus descendientes son CRec, CImage, CText. Sólo tienen propiedades específicas e inherentes.
3. Además, están las clases de plataforma de ventanas. Hay varias: ventana de menú, ventana de opciones, ventana de diálogo, ventana dinámica. Allí hay un conjunto de propiedades específicas.
3. Además, hay clases de elementos. Puede haber hasta 50 de ellos. Se dividen en categorías: 1) por método de tratamiento de los parámetros, 2) por método ornamental.
Este es un buen punto de partida. Tenemos que hacer un lenguaje de marcado, no una biblioteca. Si no, ¿qué sentido tiene?
ZS La mayoría de los controles funcionan con el parámetro que se les da. La esencia de su propósito es controlar algún parámetro del usuario. Pero, cada control lo hace de una manera diferente.
ZSY. Me olvidé de añadir - se necesita una clase base de parámetro con sus propiedades. CParam por ejemplo.
1. La clase más básica es el GOBijest (objeto gráfico básico). Debe haber propiedades x,y, x_size, y_sixe y diferentes tipos de unión de coordenadas. Son propiedades comunes a TODOS los objetos.
2. sus descendientes son CRec, CImage, CText. Sólo tienen propiedades específicas e inherentes.
3. Además, están las clases de plataforma de ventanas. Hay varias: ventana de menú, ventana de opciones, ventana de diálogo, ventana dinámica. Allí hay un conjunto de propiedades específicas.
3. Además, hay clases de elementos. Puede haber hasta 50 de ellos. Se dividen en categorías: 1) por método de tratamiento de los parámetros, 2) por método ornamental.
Este es un buen punto de partida. Tenemos que hacer un lenguaje de marcado, no una biblioteca. Si no, ¿qué sentido tiene?
ZS La mayoría de los controles funcionan con el parámetro que se les da. La esencia de su propósito es controlar algún parámetro del usuario. Pero, cada elemento lo hace de forma diferente.
Estoy teniendo una pequeña explosión cerebral... )) Todo tiene que ser dibujado, de lo contrario no se puede digerir. )
Estoy teniendo una pequeña explosión cerebral... )) Todo tiene que ser dibujado, de lo contrario no se puede digerir. )
)) Nada...
La clase base de parámetros CParam tiene varios descendientes. La cuestión es que hay propiedades generales de los parámetros de los artículos controlados, y hay otras específicas. Por ejemplo: un botón tiene un parámetro controlado de tipo bool, mientras que una lista desplegable tiene un tipo "menú". Es decir, un botón conmuta 1/0, mientras que una lista ofrece una selección limitada. El deslizador, por ejemplo, tiene un tipo de parámetro de "rango", es decir, rango. Hay otros tipos y todos tienen propiedades únicas.
Por lo tanto, las clases que descienden de la clase parámetro base también deberían serlo. Algo como "CBool", "CRange", "CMenu".
)) Nada...
La clase base de parámetros CParam tiene varios descendientes. La cuestión es que hay propiedades comunes para los parámetros de los elementos controlados, y hay otras específicas. Por ejemplo: un botón tiene un tipo de parámetro controlado bool, mientras que una lista desplegable tiene un tipo "menú". Es decir, un botón conmuta 1/0, mientras que una lista ofrece una selección limitada. El deslizador, por ejemplo, tiene un tipo de parámetro de "rango", es decir, rango. Hay otros tipos y todos tienen propiedades únicas.
Por lo tanto, las clases que descienden de la clase parámetro base también deberían serlo. Algo como "CBool", "CRange", "CMenu".
Espera. Intentemos verlo ahora de forma un poco abstracta.
Peter, desde tu punto de vista, ¿qué tienen en común controles como Button, Text label, Input box, Picture box?
Espera. Intentemos verlo ahora de forma un poco abstracta.
Peter, desde tu punto de vista, ¿qué tienen en común controles como Button, Text label, Input box, Picture box?
1. Coordenadas, dimensiones.
2. Dependencias de coordenadas, dependencias de dimensiones.
3. un montón de cosas más dependiendo del número total de propiedades en la funcionalidad del control. Tengo 270 propiedades en mi núcleo. La mayoría de ellos son comunes. Pero, tengo una funcionalidad desarrollada que soporta muchas características. Por lo tanto, tal número de propiedades. Tenemos que empezar por las propiedades más sencillas.
1. Coordenadas.
2. Coordinar las dependencias.
3. un montón de otras cosas dependiendo del número total de propiedades en la función de control. Tengo 270 propiedades en mi núcleo. La mayoría de ellos son comunes. Pero, tengo una funcionalidad avanzada que soporta un montón de características. Por lo tanto, tal número de propiedades. Tenemos que empezar por las propiedades más sencillas.
Sí, por supuesto con las propiedades más simples. ¿De qué objetos primitivos podría constar la misma Etiqueta de Texto? ¿O de qué objetos primitivos podría constar un simple Botón?