Discusión sobre el artículo "Interfaces gráficas X: Selección del texto en el campo de edición multilínea (build 13)"
¡Genial! ¿Cuál es la situación de pegar desde el búfer?
Todavía no he contactado con los desarrolladores de servicedesk con tal petición.
Probablemente, es necesario no sólo insertar desde el buffer, sino también enviar al buffer, para poder transferir texto entre los campos de entrada, si surge tal necesidad.
Lo más probable es que necesitemos la capacidad de manejar eventos del sistema causados por pulsar Ctrl + X (cortar), Ctrl + C (copiar) y Ctrl + V (pegar).
Esto va a ser curioso:)
¿Mostrarás los nuevos elementos dibujados en el próximo artículo? Sería muy curioso:)
1. Sí. Todos los elementos serán finalmente elementos dibujados. Como parte de la segunda etapa de desarrollo: 1 elemento=1 objeto (lienzo para dibujar).
2. Sí. Al igual que todos los elementos que ya están dibujados utiliza esta clase CCanvas. Ya tiene métodos listos para dibujar formas gráficas simples. Es una buena clase, que si no existiera, tendrías que implementarla tu mismo. En aquellos elementos de la librería, que ya están dibujados, se utilizan métodos para dibujar pixel a pixel y líneas, salida de texto, así como formas como rectángulo, rectángulo con relleno.
...
El enfoque OOP es mucho más sencillo de lo que has descrito. Los cambios en el esquema de la biblioteca ya descritos antes son mínimos. Al final, todo será aún más cómodo y mucho mejor de lo que es ahora.
Esta misma receta de desarrollo del sistema sin su renacimiento interno es completamente desconocida para mí. Es como un grial - quiero creer que hay uno, pero es poco probable....
Por supuesto, no es muy difícil dibujar un elemento. Casi todo se puede dibujar a partir de rectángulos (excepto el gradiente), pero hay que crear otro modelo de eventos. La función OnChartEvent() ya no proporcionará la fijación de los eventos de clic en el patrón del elemento dibujado. Tampoco servirá Zorder para la priorización. Hace mucho tiempo te hablé de la creación de un mapa de objetos, y enumeré sus ventajas, pero entonces rechazaste esta solución, y ahora, no puedes ir a ninguna parte sin ella.
No hay duda de que los elementos dibujados tienen más propiedades, y la interacción con ellos es mucho más compleja. En esta tecnología, el sistema debería ser más holístico y los mecanismos más universales. Por ejemplo, debería existir una memoria común para todos los elementos de la interfaz, que contenga los valores de todas sus propiedades. Es una solución más eficaz que crear muchas matrices y variables separadas en diferentes estructuras y clases. Todas las convenciones de la POO (objetos de referencia para acceder a variables de otras clases de las que se necesita obtener el valor de alguna propiedad de algún objeto, por ejemplo) sólo ralentizarán y complicarán el trabajo, no lo simplificarán. La programación orientada a objetos tiene una desventaja más, por la cual no lamento no tener la ventaja de usar clases ajenas como tú. Un desarrollador que utiliza en su desarrollo bloques creados por otras personas, conoce peor su desarrollo que el que lo ha creado todo él, y además está más limitado en la posibilidad de mejora en su desarrollo no sólo porque lo conoce peor, sino porque no va a rediseñar bloques ajenos, ya que no se lo proporciona el "estilo profesional" de desarrollo.
Todo lo anterior es sólo mi opinión y la he dado por finalizada.
Miraré con interés el futuro desarrollo de la biblioteca.
Por supuesto, dibujar un elemento no es muy difícil. Casi todo se puede dibujar a partir de rectángulos (excepto el gradiente), pero hay que crear otro modelo de eventos. La función OnChartEvent() ya no proporcionará la fijación de eventos de clic en el detalle del elemento dibujado. Tampoco servirá Zorder para priorizar. Hace mucho tiempo te hablé de la creación de un mapa de objetos, y enumeré sus ventajas, pero entonces rechazaste esta solución, y ahora, no estás en ninguna parte sin ella.
Usted está equivocado, como siempre. Aquí hay ejemplos, donde incluso en el modelo actual no tengo los problemas que usted describió (ver GIF-animaciones a continuación). La mesa está dibujada y la interacción con ella es una de las más complicadas de todos los elementos existentes, por no decir la más complicada. Además, esta no es la versión final todavía. Tal vez ya en el próximo artículo habrá un código final para esta tabla.
//---
Por favor, muéstrame cómo has implementado lo mismo.
//---
... No hay duda de que los elementos dibujados tienen más propiedades, y la interacción con ellos es mucho más compleja. En esta tecnología, el sistema debería ser más holístico y los mecanismos más universales. Por ejemplo, debería haber una memoria común para todos los elementos de la interfaz, que contenga los valores de todas sus propiedades. Esto es más eficiente que crear muchas matrices y variables separadas en diferentes estructuras y clases.
Me resulta mucho más fácil interactuar con los elementos dibujados. Poco a poco todo será lo más universal posible. En realidad de artículo a artículo en esta serie este proceso debería ser notable, si por supuesto lees cuidadosamente y no sólo miras las imágenes. Puedes hacer una memoria compartida, o puedes simplemente proporcionar un acceso fácil desde una clase a las propiedades de cada elemento, como hice yo. No puedes afirmar categóricamente que debe ser así y no al revés. Nadie le debe nada a nadie. En tus desarrollos puedes hacer lo que te convenga. Yo prefiero tener mi propia opinión sobre tal o cual cuenta. Como me demuestra mi práctica personal y mi experiencia vital, mucho de lo que dicen los demás es erróneo. Al mismo tiempo, no me excluyo de esta cifra. Pero no tengo miedo a equivocarme y, si me equivoco, busco la forma de corregir el error.
... Todas las convenciones de POO (objetos de referencia para acceder a variables de otras clases de las que necesitas obtener el valor de alguna propiedad de algún objeto, por ejemplo) sólo ralentizarán y complicarán el trabajo, no lo simplificarán.
En tu caso - sí, en el mío - no. )
Retag Konow:
La programación orientada a objetos tiene una desventaja más, por la que no lamento no tener la ventaja de usar clases ajenas como tú. Un desarrollador que utiliza bloques creados por otras personas en su desarrollo conoce peor su desarrollo que el que lo ha creado todo él mismo, y además está más limitado en la posibilidad de mejorar su desarrollo no sólo porque lo conoce peor, sino porque no rediseñará los bloques de otras personas, ya que no se lo proporciona el "estilo profesional" de desarrollo.
En este caso, empieza desde cero y por tu cuenta. Escriba su propio sistema operativo, luego escriba un terminal de operaciones con el lenguaje MQL, y después empiece a desarrollar su propia biblioteca para crear interfaces gráficas. Después de haber hecho todo esto, podrás golpearte con orgullo el talón en el pecho. )))
//---
P.D. Y para mi la tarea era:
- Practicar programación.
- Escribir para mi mismo una libreria para crear interfaces graficas con una calidad que me satisficiera.
- Compartir este desarrollo con MQL-comunidad.
- Al menos compensar parcialmente los costes laborales del desarrollo. Gracias a MQ por apoyar el proyecto.
Creo que ha salido muy bien. Al menos no soy el único al que le gusta el resultado. :)
Anatoly, he expuesto mi opinión y no tengo ningún deseo de entrar en otra agria discusión contigo.
Mis tablas no están terminadas, pero el ejemplo que has demostrado me funciona igual. La tabla es interactiva, hay imágenes en las celdas, casillas de verificación, e incluso las columnas también cambian de ancho. Por supuesto, no todo funciona perfectamente todavía.... La apariencia es un poco diferente. Añadir columnas y columnas no está implementado todavía. No lo mostraré aquí, o seré baneado por PR de nuevo.
Todo lo que estoy hablando es de la experiencia que he ganado en el proceso de trabajo duro, y el hecho de que lo comparto, no debe ser percibido como hostil. Al fin y al cabo, ¿quién más aquí contigo podrá discutir todos estos temas en pie de igualdad?
Suerte.
Anatoly, ya he expuesto mi opinión, y no tengo ningún deseo de entrar en otra agria discusión contigo.
De acuerdo, no te distraeré. )
Mis tablas no están terminadas, pero el ejemplo que has demostrado funciona igual. La tabla es interactiva, hay imágenes en las celdas, casillas de verificación, e incluso las columnas también cambian de ancho. Por supuesto, no todo funciona perfectamente todavía.... La apariencia es un poco diferente. Añadir columnas y columnas no está implementado todavía. No lo mostraré aquí, o seré baneado por PR de nuevo.
Tienes una gran oportunidad de leer artículos sobre este tema e incluso utilizar las soluciones publicadas en el código fuente de forma fácil y sencilla adaptándolas a tu esquema.
Puedes publicar los resultados en tu blog. Sigo tus publicaciones. ;)
- 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: Selección del texto en el campo de edición multilínea (build 13):
En este artículo vamos a implementar la posibilidad de seleccionar el texto usando diferentes combinaciones de teclas y eliminar el texto seleccionado, de la misma manera como se hace en cualquier otro editor de texto. Además de eso, seguiremos optimizando el código y prepararemos las clases para el traspaso al proceso final de la segunda fase del desarrollo de la librería, cuando todos los controles estarán dibujados en las imágenes separadas (lienzos para el dibujado).
Los métodos para la selección del texto están implementados, pues así se mostrará todo eso en una aplicación final:
Fig. 6. Demostración de la selección del texto en el campo de edición de una aplicación MQL.
Autor: Anatoli Kazharski