Realización de un proyecto crowdsourced en Canvas - página 6
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
Hay una cuestión fundamental.
Digamos que hay dos aplicaciones, paneles, indicadores, en un gráfico. ¿Debe cada uno de ellos dibujar en su propio lienzo o ambos en uno común?
En ambos casos hay dudas.
Ahora sugiero que simplemente dibujemos algún lienzo. Con todos los elementos en él.
De todos modos, no podremos controlar el número de tales instancias en ejecución con canvas (o nos adentraremos en las funciones del SO para la "interfaz multiventana" en canvas. Puede que se llegue a esto en algún momento, pero todavía no).
Como consecuencia - propongo no hacer interacciones entre kanvas a nivel de enviar "eventos de ventana" entre ellos ahora mismo.
Además, ahora mismo no puedo imaginar cómo varios ex5 podrían intercambiar datos sobre el contenido de un único kanvas compartido.
Con el teclado, todo está más o menos claro. Hay un evento cuando se pulsa una tecla, hay un código para esa tecla. ¿Qué más quieres?
Desgraciadamente, el código no es completo. Hoy en día los eventos del gráfico no distinguen entre A y a
Ya escribí sobre este tema en la SD
Por cierto, creo que facilitaría mucho la vida en términos de un DND normal introduciendo el evento OnMouseDown.
El evento CHART_MOUSE_MOVE en sparam envía el estado de los botones y el teclado. = izquierda, derecha, ctrl, shift, alt.
En otras palabras, el DND ya está implementado.
En otras palabras, ya podemos implementar el DND.
Sí, soy consciente de ello, porque lo he implementado en mi reciente proyecto. Así que ahora el DND puede ser implementado sólo a través de un idiota.
En primer lugar para el arrastre normal es necesario habilitar o deshabilitar algunas propiedades del gráfico, de lo contrario el gráfico se arrastra junto con el lienzo, por supuesto en casi cualquier caso debemos deshabilitarlas.
En segundo lugar, MouseMove no está ligado a un objeto, como Click, por ejemplo, así que si hay dos objetos bajo el ratón, ambos serán arrastrados. En la biblioteca estándar, esto es así, por cierto.
Y será así si no hay una lógica interna, seleccionando qué objeto tirar.
Así, el segundo problema del evento MoseDown parece estar efectivamente resuelto.
También hay un tercer punto. MouseMove es un evento de spam. Se debe forzar su habilitación y cuando se habilita, se enviará a todos los códigos de la carta y puede ser la causa de buenos frenos debido al número de mensajes, así que si hay una manera de no usarlo, es mejor no usarlo.
Oh, también hay un tercer punto. MouseMove es un evento de spam. Tiene que ser habilitado a la fuerza y cuando se habilita se enviará a todos los códigos del gráfico y puede causar buenos retrasos debido al número de mensajes, así que si hay una manera de no usarlo, es mejor no usarlo.
Sí, soy consciente de ello, porque lo he implementado en mi reciente proyecto. Así que ahora el DND puede ser implementado sólo a través de un idiota.
La primera, para el arrastre normal necesitamos desactivar y activar algunas propiedades del gráfico, de lo contrario el gráfico se arrastra junto con el lienzo, por supuesto en casi todos los casos hay que desactivarlas.
En segundo lugar, MouseMove no está ligado a un objeto, como Click, por ejemplo, así que si hay dos objetos bajo el ratón, ambos serán arrastrados. En la biblioteca estándar, esto es así, por cierto.
Y será así si no hay una lógica interna, seleccionando qué objeto tirar.
Así, el segundo problema del evento MoseDown parece estar efectivamente resuelto.
También hay un tercer punto. MouseMove es un evento de spam. Se debe forzar su habilitación y cuando se habilita, se enviará a todos los códigos de la carta y puede ser la causa de buenos frenos debido al número de mensajes, así que si hay una manera de no usarlo, es mejor no usarlo.
Te das cuenta de que si vamos a kanvas - estamos por nuestra cuenta. Ya no hay eventos de alto nivel. No hay objetos mt que puedan recibirlos
Si sólo los movimientos del ratón y los estados de los botones. yo no lo llamaría un gilipollas )). es sólo un evento de bajo nivel.
Si hay algún retraso, es invisible a simple vista. En mi panel en un momento dado MouseMove estaba enviando miles de elementos, incluso invisibles, entonces hice un envío más inteligente, pero visualmente no añadió velocidad.
No puedo decirte lo rápido que va a ser.
Nad miles de objetos no hacen una diferencia en la velocidad.
te das cuenta de que si entramos en el sorteo, estamos solos. Ya no hay eventos de alto nivel. No hay objetos mt para recibirlos.
Si sólo los movimientos del ratón y los estados de los botones. yo no lo llamaría un culo )). es sólo un evento de bajo nivel.
También está el nivel de interacción con otros códigos. Al menos, entre varias instancias de un indicador, por ejemplo. Deberías tenerlo en cuenta.
Pero sí, todo esto está claro.
También hay un nivel de interacción con otros códigos. Por ejemplo, entre varias instancias de un indicador. Hay que tenerlo en cuenta.
Sinceramente, no tengo ni idea de qué tipo de interacción estás hablando.
¿Pueden salir varias instancias de un indicador en un mismo lienzo?