Interfaz gráfica de usuario de origen colectivo. Prueba beta abierta. - página 8
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
que todo va a la configuración de estilo habitual. Hay ciertos momentos, como el botón de enlace, el botón hover, el botón de clic, y sólo el botón. Y para cada momento suelen hacer sus propios estilos, o una mezcla de ellos.
A decir verdad, siempre he entendido mal en este tipo de cosas cómo organizar la configuración del código ejecutado para un botón. Para que sea también visual. Y también con sus propias comprobaciones del código en busca de errores.
Un ejemplo claro de este tipo de trabajo sería la creación de un menú para crear una carta. Es decir, si gráficamente se podrá hacer el menú de la izquierda o de la derecha con código incrustado por así decirlo sobre la marcha.
¿O sólo genera botones en code....?
La configuración de los estilos es sólo el comienzo de la edición. A continuación, el número de funciones crecerá en forma de avalancha. La tarea principal consiste en arrastrar y soltar las características básicas del lenguaje de marcado en el editor visual. No es difícil de hacer. Diría que hay una especie de avance a nivel visual, como atravesar una barrera supersónica. Es difícil de describir... - es como si las posibilidades estuvieran encerradas bajo un candado y ahora, cuando vas a visualizarlas, la puerta se abre y se amontonan. Sólo hay que ponerlo en práctica.
Próximas tareas:
1. Añadir ventanas.
2. Eliminación de elementos.
3. Creación de una nueva herramienta - marco azul.
4. Copiar elementos dentro de la ventana.
5. Ampliación del enfoque de la edición.
6. Añadir objetivos de edición.
7. Selección y carga de proyectos guardados.
8. Actualizar el motor.
...
//------------------------------------------------
El código no se genera esencialmente. Se genera un núcleo que contiene los elementos de la descripción numérica. Es leído por el motor adjunto a la aplicación del usuario y gestiona la comunicación bidireccional.
Configurar los estilos es sólo el principio de la edición. A continuación, el número de funciones crecerá como una avalancha. La tarea principal consiste en arrastrar y soltar las características básicas del lenguaje de marcado en el editor visual. No es difícil de hacer. Diría que hay una especie de avance a nivel visual, como atravesar una barrera supersónica. Es difícil de describir... - Es como si las posibilidades estuvieran encerradas bajo un candado y ahora, cuando vas a visualizarlas, la puerta se ha abierto y se acumulan. Sólo hay que ponerlo en práctica.
Próximas tareas:
1. Añadir ventanas.
...
//------------------------------------------------
El código no se genera esencialmente. Lo que se genera es un núcleo que contiene los elementos de la descripción numérica. Es leído por el motor adjunto a la aplicación del usuario y gestiona la comunicación bidireccional.
Lo que me gustaría: crear un estilo base y editarlo, crear estilos por defecto. Personalizar el estilo del botón por separado. Hay que hacer más hincapié en las plantillas de estilo, tomando algo de la tendencia moderna.
Posibilidad de editar al menos parte del código de los archivos de usuario sobre la marcha. Por ejemplo, la llamada de ciertas clases o la lista que se mostrará. En consecuencia, debe ser la norma de una determinada respuesta para su posterior tratamiento posterior.
Es lógico que haya una posibilidad de edición visual - pero es sólo el primer paso, en el que creo que es lógico utilizar el botón derecho y hacer que haya un menú definido. En general, es más fácil hacer el código independiente - porque en el futuro puede necesitarlo no sólo para trabajar en MT. Al menos en los inlays, si lo hacemos para el mercado.
Por lo general, en este tipo de direcciones cada nuevo paso conduce a más problemas en el código, a menudo parece que todo se puede hacer en una cierta cantidad de tiempo, pero en realidad lleva mucho más tiempo. Y esto siempre será así, la avalancha figurativa sólo aumentará la funcionalidad después del lanzamiento de la primera versión totalmente operativa.
Lo que sería deseable: crear un estilo base y editarlo, crear estilos por defecto. Personalice el estilo del botón por separado. Hay que poner más énfasis en las plantillas de estilo tomando algo de la tendencia moderna.
Posibilidad de editar al menos parte del código de los archivos de usuario sobre la marcha. Por ejemplo, una llamada para ciertas clases o una lista, que necesita ser mostrada. Por lo tanto, debe haber una respuesta estándar para el procesamiento posterior.
Es lógico que haya una amplia posibilidad de edición visual - pero es sólo el primer paso, donde creo que es lógico utilizar el botón derecho y hacer que haya un menú definido. En general, es más fácil hacer el código independiente - porque en el futuro puede necesitarlo no sólo para trabajar en MT. En consecuencia, los archivos son enchufables. bueno, al menos en los inludios si lo hacemos para el mercado
Pensaré en guardar las plantillas de estilo. En un lenguaje de marcado, esto era fácil. Allí, la cadena de propiedades podría simplemente copiarse de elemento a elemento y quedaría bien. Aquí no tenemos una cadena directa, pero ¿qué problema hay en hacer una? Creo que podría ser mejor y más sencillo. Algo así como un conjunto de estilos con valores guardados de las propiedades de las plantillas...
Sobre la posibilidad de editar archivos utilizables - no se entiende muy bien de qué estamos hablando exactamente. Un ejemplo sería...
Se imprimen los archivos necesarios para la conexión. Hay dos. Contienen la información de carga para el motor y la api para la aplicación del usuario. Para que se "comunique" con los elementos.
Imprimir texto en los elementos.
piense en la rejilla: se necesita algún tipo de alineación/alineación. ya es difícil alinear tres elementos de manera uniforme
Estoy de acuerdo. Lo pensaré.
Piensa en la rejilla: se necesita algún tipo de alineación/vinculación.
Sí, toda esta red es 10 veces ......
Hay que ver el interés del usuario. Por ejemplo, si fuera posible crear tal o cual gráfico sobre la marcha... por ejemplo dibujar una línea por máximos y demás.
Porque hasta ahora no es más que una muy buena lección para el autor en el diseño de programas. La creación de un menú no es tan interesante. Y las llamadas a las funciones deben provenir de un botón.
Aunque, debido a la popularización del canvas en html, hay un interés deportivo por implementar algo universal. Pero es demasiado complicado para mí
....
Hay que reconocer que existe otra opción: limitarse a la generación de código. Como un "inludnik" con toda la disposición de los botones está creado y todo lo que queda es introducir los datos ....... - también una variante. PD: La opción más cercana y viable
Mi objetivo es aplicar la siguiente lista de tareas antes del 3 de marzo:
1. Añadir/quitar ventanas.
2. Eliminación de elementos.
3. Creación de una nueva herramienta - marco azul.
4. Copiar elementos dentro de la ventana.
5. Ampliación del enfoque de la edición.
6. Añadir objetivos de edición.
7. Selección y carga de proyectos guardados.
8. Actualizar el motor.
9. Rejilla y autocorrección de las posiciones de los elementos.
//------------------------------------------------
Después, el editor visual puede utilizarse para crear una interfaz similar a la de Windows para las aplicaciones personalizadas.
(sic. con un conjunto de elementos simples. A continuación, se presentarán cuadros y listas diversas).
Peter inventó y escribió Windows. Sólo 30 años tarde =)
Siguiendo los pasos de los gigantes).