Galería de interfaces de usuario escritas en MQL - página 71

[Edgar Akhmadeev]

Реter Konow #:
Es una táctica extraña acechar y esperar. :) Si la gente participara activamente, no cambiaría mis prioridades.

Sólo hablaré por mí. No sé cómo ayudar. Cómo participar activamente. Todo lo que he podido hacer, lo he hecho. He escrito el código basándome en la información que tengo, he creado una bonita interfaz. Entonces estoy atascado en no realizar lo que necesito personalmente. Y no puedo estudiar lecciones sobre cómo utilizar lo que aún no puedo poner en práctica. Soy un practicante. Por eso definitivamente necesitaré lecciones cuando llegue su momento.

Botones de control diferentes, y botones para controlar cosas diferentes - personalmente, los necesitaré más adelante. Cuando llegue el momento. Por ahora estoy esperando una interfaz para una visualización cómoda y bonita. Y no tiene prisa, por eso no te empujamos por debajo de los codos. Entendemos que usted no está trabajando en servicio. Hice una pregunta no porque tengo prisa, sólo - desaparecieron en alguna parte.

[Реter Konow]

Edgar Akhmadeev #:

Sólo hablaré por mí. No sé cómo ayudar. Cómo participar activamente. He hecho todo lo que he podido. Escribí el código de acuerdo con la información disponible, y conseguí una bonita interfaz. Entonces estoy atascado en no realizar lo que necesito personalmente. Y no puedo estudiar lecciones sobre cómo usar lo que aún no puedo poner en práctica. Soy un practicante. Por eso definitivamente necesitaré lecciones cuando llegue su momento.

Botones de control diferentes, y botones para controlar cosas diferentes - personalmente, los necesitaré más adelante. Cuando llegue el momento. Por ahora estoy esperando una interfaz para una visualización cómoda y bonita. Y no tiene prisa, por eso no te empujamos por debajo de los codos. Entendemos que usted no está trabajando en servicio. Hice una pregunta no porque estoy en un apuro, sólo - desaparecido en alguna parte.

Como me he dado cuenta, aún no sabes qué interfaz necesita tu aplicación. :) No puedo ayudarte en eso. Pero cuando lo sepas, haz un boceto. Es probable que las capacidades existentes de mi diseñador y motor sean más que suficientes. Como ya he dicho, sólo faltan tres cosas principales:

1. Las tablas dinámicas son tablas con un número ilimitado de filas.

2. 2. Tablas generadas - son tablas recogidas por la función "sobre la marcha". Son necesarias para la salida rápida, clasificación y comparación de parámetros individuales tomados de grandes conjuntos de datos.

3. Gráficos científicos como los de R. Ya están implementados en la biblioteca estándar CGraphic y en la biblioteca de Anatoly Kozharsky. Yo los implementaré a mi manera.

Todo lo demás está en mi constructor. Piensa en lo que necesita tu aplicación. Haz un boceto. Publícalo aquí. Te ayudaré a escribir Kib-code.

[Реter Konow]

Edgar Akhmadeev #:

... Escribí el código de acuerdo con la información disponible y obtuve una hermosa interfaz. Entonces me encontré con no realizado lo que necesito personalmente. ....

Por cierto, lo que no funcionaba entonces, ya funciona, porque hay un control de software de la interfaz. Recuerdo que entonces no se podía dar salida a los parámetros de las tablas. Ahora es fácil hacerlo. Tu tabla puede funcionar y dar valores de salida. Ya está implementado en el motor. Eso es sólo para el registro.

[Edgar Akhmadeev]

No sólo sé lo que se necesita, pero he hecho la maqueta. Aquí está su código corregido y diseño https://www.mql5.com/ru/forum/467909/page37#comment_53863397.

Necesito exactamente (en tus términos) tablas dinámicas y generadas. Es decir, añadir programáticamente un número indefinido de filas (bueno, limitado por el sentido común), rellenarlas, desplazar convenientemente la tabla en sí, no el marco con ella. Para que los encabezados se mantengan en su sitio.

Esto es lo que tiene en marcha hasta ahora. Por eso estoy tranquilamente con el culo al aire y esperando. Yo no tengo prisa, y no tengo prisa por ti. Voy a vivir para siempre. Hasta ahora está funcionando.

[Реter Konow]

Edgar Akhmadeev #:

No sólo sé lo que se necesita, sino que he hecho la maqueta. Aquí está su código corregido y diseño https://www.mql5.com/ru/forum/467909/page37#comment_53863397

Necesito exactamente (en tus términos) tablas dinámicas y generadas. Es decir, añadir programáticamente un número indefinido de filas (bueno, limitado por el sentido común), rellenarlas, desplazar convenientemente la tabla en sí, no el marco con ella. Mantener los encabezados en su sitio.

Esto es lo que tiene de momento en marcha. Por eso estoy tranquilamente con el culo al aire y esperando. Yo no tengo prisa, y no tengo prisa por ti. Voy a vivir para siempre. Hasta ahora está funcionando.

Ya veo. Bueno, las tablas dinámicas y generadas son necesarias para mí y para ti, así que lo serán. Intentaré terminar todas las tareas antes de Año Nuevo.

[hini]

¿Hasta dónde hemos llegado?

[Реter Konow]

hini #:
¿Hasta dónde hemos llegado?

Hoy en día se está formando el concepto de tablas dinámicas y generadas, que se supone que funcionan al unísono con los gráficos científicos. La tarea no es sólo desarrollar la parte técnica - tablas y gráficos - sino también encontrar formas de "simbiosis" de estas herramientas en el trabajo analítico.

He aquí un ejemplo:

1. Los datos se cargan en un archivo. Algoritmos especiales los distribuyen en tablas, filas y columnas.

2. El usuario accede a la tabla deseada, selecciona una fila y hace doble clic para dibujar una curva o un diagrama utilizando las cifras de esa fila o columna.

3. El usuario selecciona la celda requerida de la tabla y llama a la construcción de una nueva tabla por los datos asociados al parámetro situado en ella.

4. El usuario pasa de tablas a gráficos, de gráficos a tablas y gráficos circulares, montando o generando "sobre la marcha" nuevas tablas y gráficos. Mediante simples clics e introduciendo parámetros en la ventana, puede ver los datos desde diferentes "ángulos" y en distintas combinaciones dentro de las representaciones gráficas que aparecen.

Todo ello contribuye sin duda a un trabajo productivo y a la búsqueda de relaciones y patrones en los datos.

Tengo previsto implantar un cómodo sistema de trabajo dinámico con datos a través de tablas, gráficos y diagramas.

Lo más importante es el concepto adecuado. Es lo que más tiempo lleva formar. La aplicación técnica lleva relativamente poco tiempo.

P.S. Además, estoy preparando mi primer artículo sobre GUI builder y lenguaje de marcado.

P.S.S. Para cuando se publique el artículo, prepararé una versión para el codebase, para que los que lo deseen puedan descargar el constructor.

En general, hay mucho trabajo).

[Реter Konow]

Te diré cuáles son mis planes.

1. Crear un libro de texto sobre el lenguaje de marcado.

Es necesario recopilar un libro de texto completo sobre lenguaje de marcado, organizándolo en partes, capítulos y temas.

2. 2. Escribir artículos sobre el constructor de interfaces y el lenguaje KIB.

Dividir el material didáctico terminado en una serie de artículos, añadiéndoles códigos, diagramas, imágenes y gifs.

3. Antes de publicar el primer artículo, abre un hilo especializado con el único propósito de publicar plantillas de código KIB. Aquellos que lo deseen podrán construir fácilmente una GUI tomando prestadas partes ya hechas. También podrán añadir códigos KIB si lo desean.

4. Antes de publicar el primer artículo, publica la última versión del constructor en la base de código.

En esa página publica un manual de instrucciones detallado con imágenes, gifs y vídeos.

5. Al principio del artículo pon un enlace al constructor y a las instrucciones de instalación, y al final del artículo deja un enlace a la rama con las plantillas. Así, inmediatamente después de leer el artículo, los lectores podrán intentar crear una interfaz gráfica, tomando prestadas ventanas o grupos de elementos ya creados. Luego, a medida que vayan aprendiendo, experimentarán y mejorarán sus interfaces.

6. En mi opinión, para facilitar a los lectores la comprensión y el rápido dominio de las capacidades del diseñador, es necesario simplificar la presentación del material y abundar en los artículos con imágenes informativas, esquemas legibles y códigos comentados. Por eso escribiré artículos con el lema "cuanto más simple, mejor", esforzándome por la simplicidad lógica y la claridad de significado.

7. Antes de publicar el constructor en la base de código, necesito hacer algunos trabajos preliminares:

a) Traducir los nombres de los catálogos al inglés.

b) Eliminar completamente todas las advertencias que aparecen al compilar el constructor (no el código KIB).

c) Arreglar algunos errores detectados anteriormente en el trabajo de los controles.

d) Poner un "stub" para depurar código de usuario conectado al motor.

De acuerdo con la idea, el motor se apagará durante la depuración simplemente comentando su línea, y sólo el núcleo gráfico y las funciones wrapper del archivo de servicio "UIDATA.mqh" permanecerán conectadas. Todas las demás funciones regulares del constructor se establecerán como "funciones vacías" que servirán como "tapones" en un archivo especial. La línea de este archivo será descomentada por el usuario antes de depurar.

Este es el concepto, pero aún no lo he comprobado en la práctica.

8. El primer artículo será el más difícil para mí, porque requerirá que describa brevemente todo el constructor y el lenguaje de marcado, dando a los lectores una idea completa de su propósito, capacidades y dispositivo. Además, enumeraré el contenido de futuros artículos y añadiré un esquema claro de la futura distribución del material educativo.

En mi opinión, los artículos son lecciones y, por tanto, la presentación del material debe ser pedagógica.

P.D. Inicialmente decidí basarme en el ejemplo de los conocidos artículos sobre interfaz gráfica de Anatoly Kozharsky - Easy and Fast library. Para mí es el resultado más completo que revela este tema. Al mismo tiempo, reconozco respetuosamente la contribución de otros autores con talento que hicieron valiosos intentos de crear bibliotecas de interfaz gráfica de usuario antes y después de los artículos de Anatoly. Me gustaría mencionar especialmente a Dmitry Fedoseev y Artem Trishkin.

Y así, habiendo aceptado los artículos de Anatoly como un estándar de calidad y un indicador de profesionalidad, "probé" su formato con mi propio material y me vi obligado a reconocer la incompatibilidad. Las diferencias de enfoque y realización son demasiado grandes. Por lo tanto, tendré que encontrar y pulir mi estilo, sin olvidar cumplir el alto nivel autoral establecido por mis predecesores.

[Реter Konow]

El proceso de trabajar en el editor visual GUI en MT5.

Hace 4 años:

(Haga clic en la imagen).

P.S. El contexto de la demostración se describe en el post de abajo.

[Реter Konow]

Pasa el tiempo, y la idea de un editor visual sigue viviendo en mi mente. No quiere abandonarme. Y cuando pienso en ello tranquilamente, cada vez me hago la pregunta "¿cuál es el problema? - Ya lo he creado, sólo que no está encendido".

En la prolongación de la reflexión vuelvo a las mismas conclusiones: las funciones básicas del editor visual ya están presentes en mi aplicación, y sólo faltan herramientas complejas. Sin embargo, las cosas complejas se pueden crear a través del lenguaje de marcado, que en la práctica es mucho más rápido y cómodo que en el modo visual.

Como ejemplo, tablas y listas de árbol - es largo y doloroso componerlas manualmente, pero es fácil y rápido escribirlas en kib code.... especialmente cuando se utilizan plantillas. Entonces, ¿por qué molestarse en inventar engorrosas herramientas de edición visual para tablas y listas cuando puedes construirlas con un simple copiar y pegar? No tiene sentido, está bastante claro. Pero entonces, ¿cuál es el problema?

Muy sencillo. Se trata de combinar el trabajo del lenguaje de marcado y las capacidades actuales del editor visual. No es necesario añadir nada nuevo ni al primero ni al segundo, sólo hay que combinarlos de forma que se complementen.

Tras reflexionar seriamente sobre esta cuestión, he llegado a la conclusión de que incluso si ahora existiera la oportunidad de cambiar completamente a la construcción visual de GUI, me negaría. La razón es que no quiero perder la oportunidad de utilizar plantillas de código kib y el simple copiar y pegar de elementos o propiedades en el entorno del lenguaje de marcado. Es una ventaja demasiado valiosa. Quizás, no sólo para mí, sino para todos los futuros usuarios que podrán compartir sus desarrollos o simplemente copiar partes de sus desarrollos anteriores. Es algo indispensable.

Es decir, es absolutamente imposible renunciar a un lenguaje de marcado en aras de un editor visual. No lo entendía antes....

Y así, hoy el problema es desarrollar un sistema de combinación armoniosa de las capacidades del lenguaje y del editor visual. Y en realidad, técnicamente, es bastante fácil de hacer. (1) En primer lugar, todas las funciones necesarias del editor visual se escribieron y probaron hace varios años, (2) y en segundo lugar, los mecanismos clave del lenguaje de marcado se han ajustado bien en los últimos meses y se ha llevado a cabo una importante actualización con la adición de la gestión de la interfaz de software. En otras palabras, todo está listo para la integración y la fusión, y la tarea consiste únicamente en reflexionar sobre el concepto de interacción sin conflictos de ambas funcionalidades en el proceso de modelado y construcción de una interfaz gráfica.

Conceptualmente, el lenguaje de marcado y el editor visual REALMENTE entran en conflicto.

Hay varias razones que dificultan esta tarea:

Recordemos que los elementos y ventanas de la interfaz gráfica de usuario se escriben en código de forma estándar, pero también pueden crearse en un editor visual, como se muestra en el gif anterior.

1) Tanto en el primer caso como en el segundo, la funcionalidad del constructor construye el núcleo gráfico, aunque de formas diferentes, pero como las capacidades del editor visual son más débiles que las del lenguaje, los elementos creados no aceptan un conjunto completo de ajustes del usuario a través del editor. Los ajustes se pueden complementar escribiendo un editor, pero entonces el lenguaje de marcado se vuelve innecesario, y esto es malo, porque no hay posibilidad de confiar en las plantillas de código. No se puede renunciar al lenguaje de marcado, y punto.

2) Cuando se crean nuevos elementos y ventanas en modo visual, el lenguaje de marcado no los "ve". Es decir, el lenguaje de marcado no se actualiza durante la construcción visual de la GUI. No se "añade" nada al código kib original. Este hecho conduce de nuevo a la separación conceptual entre el editor visual y el lenguaje de marcado. Se trata de un conflicto.

Entonces, ¿cómo ser y qué hacer en esta situación? ¿Cuál es el compromiso que conduce a la simbiosis de dos potentes herramientas de creación de interfaces gráficas de usuario?

Intentaré comprender la solución:

Punto principal: limitar el papel del editor visual en el modelado de la interfaz, dejando las características del lenguaje sin cambios. En la práctica, esto significa:

1. Rechazar la creación de nuevos elementos y ventanas en modo visual, ya que el código de marcado no se actualiza al añadirlos.

2. 2. Dejar la posibilidad de editar posiciones y establecer propiedades de elementos y ventanas de la GUI de usuario a través de las ventanas de configuración del editor visual, sobre los valores por defecto y personalizados del usuario en el código kib. En este caso, el editor escribirá y guardará un archivo especial con anulaciones de valores, desde el cual los cargará en el kernel y los asignará a los elementos. De hecho, esto significa un nuevo tipo de plantillas de elementos "procesadas" en el editor. No entrarán en conflicto con las plantillas de código kib, sólo anularán los valores de propiedad establecidos en ellas.

Esto, en mi opinión, es una simbiosis efectiva entre el editor y el lenguaje de marcado.

P.D. Lo irónico es que técnicamente es posible realizar la idea de fusionar las capacidades del editor y del lenguaje en unos pocos días, y es bastante realista, pero pensar en todos los detalles de su integración e interacción en el trabajo del usuario.... requiere más tiempo. :)

P.D. Pero la conclusión principal es que PUEDEN y deben trabajar juntos, complementándose.