Interfaz gráfica de usuario de origen colectivo. Prueba beta abierta. - página 29
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
Bueno, había un medio ejemplo. Está claro que hay algún archivo como pieza de una función de trabajo. Donde se genera el interruptor (botones) y tenemos la posibilidad de escribir reacciones a las pulsaciones de los botones.
Sí, esto es un medio ejemplo. No pude llegar al final por culpa de ese error con las posiciones.
Err qué otras funciones seleccionar... no es necesario hacer nada de esto. Generar un archivo en el que, según entiendo, se asignan los botones válidos al interruptor.Eso es todo. Punto y aparte. A partir de aquí, cada uno debe expresar sus reacciones a este botón. Por ejemplo para guardar que fue presionado o algo así. El entorno para la retroalimentación de la presión creo que es innecesario.
Err, qué otras características elegir... No hay necesidad de nada de eso. Generar un archivo en el que, según entiendo, se asignan los botones válidos al interruptor.Eso es todo. Punto y aparte. A partir de aquí, cada uno debe expresar sus reacciones a este botón. Por ejemplo para guardar que fue presionado o algo así. El entorno para la retroalimentación de la presión creo que es innecesario.
Es mejor trabajar en el diseño
Err, qué otras características elegir... No hay necesidad de nada de eso. Generar un archivo en el que, según tengo entendido, se asignan botones válidos al interruptor.Eso es todo. Punto y aparte. A partir de aquí, cada uno debe expresar sus reacciones a este botón. Por ejemplo, para guardar que fue presionado o algo así. El entorno para la retroalimentación de los clics creo que es innecesario.
Y aquí es mejor implementar el entorno a través de las clases. También llamar al menú de pestañas, etc. etc.
Err, qué otras características elegir... No hay necesidad de nada de eso. Generar un archivo en el que, según entiendo, se asignan los botones válidos al interruptor.Eso es todo. Punto y aparte. A partir de aquí, cada uno debe expresar sus reacciones a este botón. Por ejemplo para guardar que fue presionado o algo así. Creo que el entorno para la retroalimentación es innecesario.
Y el entorno debe implementarse a través de las clases. También las llamadas al menú de pestañas, etc.
No agitemos la expresión "necesitamos clases" delante de las narices de Peter. Esperemos al menos el vídeo, luego haremos preguntas.
Ya he sugerido a Peter que modifique su "núcleo" con una variante muy sencilla: utilizar estructuras. Al diablo con estas clases, si una persona no quiere hundirse en ellas - es su propio negocio.
Pero el uso de estructuras simplemente facilitaría la vida del propio Peter.
El aspecto del "núcleo", también conocido como array global, es ahora: un array multidimensional, bueno, al menos bidimensional. La segunda dimensión contiene propiedades de un determinado tipo de control por índices. También se puede acceder a las propiedades por su nombre, ya que los índices se sustituyen por definiciones y obtenemos una "pseudo-referencia" por su nombre. De hecho, todo se construye sobre defines, como ese "lenguaje de marcas" en el código de Peter.
Ya he sugerido que Peter debería implementar una estructura, por lo que la matriz global podría ser unidimensional y las propiedades podrían ser referidas directamente por su nombre. También se simplificaría el "núcleo" del edificio, ya que bastaría con añadir nuevos puntales a la estructura original y referirse a ellos por su nombre. Y el propio código podría acortarse eliminando la lista de numerosas definiciones y métodos para utilizarlas.
Por un lado no es una clase, pero por otro lado facilitaría mucho el manejo de la matriz global a Pedro. Además, Peter ya tiene experiencia en trabajar con una estructura similar: un sindicato.
Pero Peter tiene su propia manera de sensei y sólo esperaremos el resultado...
Propongo el siguiente esquema como ejemplo transversal: Cree un formulario con tres campos: importe de la operación, precio SL y precio TP, dos botones: COMPRA y VENTA
Cree un Asesor Experto, conecte la GUI como un inluder. Añade una variable para la oferta inicial. Cuando se inicializa, el importe inicial de la puja se pasa al campo correspondiente de la interfaz gráfica de usuario.
Cree en el Asesor Experto la función "Open Deal". Esta función debe ser llamada tan pronto como se haga clic en uno de los botones de la GUI.
En la propia función se "averigua" qué comando se ha dado y también se pregunta a la GUI qué tarifa se establece ahora y en base a estos datos se abre el trato correspondiente.
Sugiero el siguiente esquema como ejemplo transversal: Cree un formulario con tres campos: importe de la operación, precio SL y precio TP, dos botones: COMPRA y VENTA
Cree un Asesor Experto, conecte la GUI como un inluder. Añade una variable para la oferta inicial. Cuando se inicializa, el importe inicial de la puja se pasa al campo correspondiente en la interfaz gráfica de usuario.
Cree en el Asesor Experto la función "Open Deal". Esta función debe ser llamada tan pronto como se haga clic en uno de los botones de la GUI.
En la propia función se "averigua" qué comando se ha dado y también se pregunta a la GUI qué tasa se ha establecido ahora y en base a estos datos se abre el trato correspondiente.
No lo entiendes.
Por qué, esto también es implementable a través de una función que se llama cuando el campo se llena y el valor de entrada es del tipo de plantilla... todo. Incluso que sea como la cadena.... todavía no habrá llenado de alta velocidad del campo