Errores, fallos, preguntas - página 519
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
Ponga un ejemplo de una de las muchas tareas en las que puede ser necesario establecer múltiples prioridades.
No tiene mucho sentido enumerar ejemplos, porque puede que no haya muchos ahora, pero muchas tareas surgirán en el proceso de desarrollo de tal o cual código en el futuro y se acumularán como un problema y como otro ejemplo. Si no pides implementarlo ahora, sentirás la necesidad dentro de medio año de todas formas.
Hasta ahora, en este sentido, sólo un problema, pero concreto, se ha hecho inminente: después de dibujar suavemente las líneas dispersas, es imposible eliminar manualmente los objetos gráficos superpuestos en orden lógico descendente de importancia (la importancia está directamente relacionada con la antigüedad relativa de cada uno de los marcos temporales) justo desde un gráfico, sin llamar al cuadro combinado"Lista de objetos". Me gustaría que fuera así: en cualquier circunstancia, programáticamente (estableciendo la propiedad de prioridad visual a un valor necesario) los objetos de diferentes TFs se agruparían entre los similares (es decir, no necesariamente superponiéndose, sino también apretándose entre ellos) en orden ascendente de importancia, de modo que el más alto sería el más importante, y en el análisis manual en orden inverso se podría llegar a los menos importantes en orden. Y todo esto se haría de forma científica, con programación de gradación secuencial a través de una propiedad, y no con trucos como quién creó más tarde y quién está encima (porque en tareas de marcado gráfico hay muchos casos en los que los objetos de diferentes TFs no se generan en un estricto orden recto, sino simplemente un desorden), lo que lleva al caos en la primacía visual. E incluso OBJPROP_ZORDER no ayudará aquí, porque el ajuste programático del orden de acceso a un objeto sólo proporcionará una prioridad de selección con el ratón, pero el objeto requerido a menudo será anulado por el más alto, pero lo que usted quiere ver inmediatamente, sin profundizar en las sub-ventanas como "Propiedades del objeto", etc. Al fin y al cabo, cuanto más agradable es trabajar con una interfaz gráfica, más clara es y menos hay que hacer para averiguar algo o para realizar una última manipulación -a propósito- con ella.
¿Y por qué no podemos comparar objetos? Las líneas de los diferentes TFs tienen un precio definido. Así que compara el precio. Si los precios son iguales, traza la línea más importante (en tu opinión). Esta será la priorización.
Para empezar, le informo de que, por ejemplo, un objeto como la línea vertical no tiene precio. Sólo existe el tiempo. Pero si ambas líneas tienen el mismo tiempo y se establecen desde diferentes marcos temporales, la línea del marco temporal más joven podría establecerse en último lugar y superponerse visualmente a la línea del más antiguo. Por supuesto, es posible nombrar los objetos (por ejemplo, añadiendo el nombre del marco temporal al final del nombre del objeto) y luego compararlos, pero puede servir de ayuda excepto para la búsqueda de objetos anclados, y no en el orden de su posicionamiento inicial.
Así que, por el momento, no hay nada para establecer la prioridad de visibilidad simple y bellamente a voluntad del usuario y no al dictado de las circunstancias objetivas en el mercado, más aún a la escucha simultánea "aleatoria" del mercado a diferentes TFs.
¿No puedes comparar los tiempos?
Como no cabe, esta propiedad se refiere al aspecto de la selección de un objeto gráfico con el ratón, no al orden de representación.
Entonces sugiero que se escriba una solicitud al SR, porque en mi opinión el orden de selección debería ser el mismo que el orden de visualización - de lo contrario es completamente contraintuitivo. Lo que hay que destacar es lo que está en la "superficie". Se supone que el zorder está ahí para que los objetos puedan "desligar" su prioridad del orden de creación.
El problema, según entiendo, es que una línea bloquea a la otra. Hay que priorizar para poner en primer plano la línea que es significativa (para ti). Si los tiempos de todas las líneas son diferentes, entonces la prioridad no es importante porque las líneas no se superponen. Te interesan los momentos en los que las líneas se solapan. Ese es el punto de contar - los tiempos de las líneas cuando los tiempos son los mismos. ¿O he entendido mal su problema?
Una vez más, el resaltado está bien y la prioridad se puede establecer. La prioridad de renderización es mala. Y "el orden de selección debe coincidir con el orden de representación" es una conclusión dudosa. El orden de cualquier cosa no debe nada a nadie por sí mismo. Debería ser posible, a discreción del usuario, establecer cualquier prioridad a los objetos que lo requieran para facilitar la percepción/acceso/manipulación/etc. Tal vez haya un bicho raro que viva en un entresuelo y duerma con las aletas colgando de la cabeza: el orden obvio no le servirá, pero para este bicho raro también debería haber una forma de establecer el objeto prioritario que considere más lógico.
¿Por qué "otra vez"? ¿No lo entiendes? Sugerí una versión funcional, la única lógica: zorder cambia el orden de selección y visibilidad, porque a nadie se le ocurriría seleccionar algo que no es visible en condiciones normales. Si no es obvio, sigue intentando promover los "pesos", las "prioridades" y otras características que faltan.
Sugerí una opción viable, la única lógica: zorder cambia tanto el orden de selección como la visibilidad, porque a nadie se le ocurriría seleccionar algo que normalmente no es visible.
En principio, los indicadores almacenados en caché no quieren volver a calcularse cuando se modifica un parámetro externo.
Ejemplo ejecuto el indicador con el parámetro A, obtengo los datos, cambio el parámetro de A a B, los datos no cambian, quito el indicador.
Ejecute el indicador con el parámetro B, los datos son los mismos que los del parámetro A.
Borro el indicador, cierro la terminal y espero hasta que el proceso se acabe.
Abra el terminal, inicie el indicador con el parámetro B de una vez.
Obtengo (cálculo correcto del parámetro B) datos completamente diferentes.