Erros, bugs, perguntas - página 519
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Dê um exemplo de uma das muitas tarefas em que pode ser necessário estabelecer prioridades múltiplas.
Não faz muito sentido enumerar exemplos, porque pode não haver muitos deles agora, mas muitas tarefas irão surgir no processo de desenvolvimento deste ou daquele código no futuro e irão acumular-se como um problema e como outro exemplo. Se não pedir para o implementar agora, sentirá a necessidade dentro de meio ano de qualquer forma.
Até agora, apenas um, mas um problema concreto tornou-se iminente: após o desenho suave de linhas dispersas é impossível eliminar manualmente objectos gráficos sobrepostos por ordem lógica descendente de importância (a importância está directamente relacionada com a antiguidade relativa de cada um dos períodos de tempo) directamente de um gráfico, sem chamar a caixa combinada"Lista de objectos". Gostaria que assim fosse: em qualquer circunstância, programmaticamente (ao definir a propriedade de prioridade visual para um valor necessário) os objectos de diferentes TFs seriam agrupados entre semelhantes (isto é, não necessariamente por sobreposição, mas também por compressão entre eles) por ordem ascendente de importância, de modo a que o mais importante fosse o mais importante, e na análise manual em ordem inversa poderia chegar-se aos menos importantes por ordem. E tudo isto seria feito cientificamente, com a criação de uma rigorosa gradação consecutiva via propriedade, não com truques como quem criou mais tarde e quem a supera (porque em problemas de marcação gráfica há muitos casos em que objectos de diferentes TFs são gerados não numa sequência directa estrita, mas com uma confusão), o que leva ao caos na primazia visual. E mesmo OBJPROP_ZORDER não ajudará aqui, porque a definição programática da ordem de acesso a um objecto só dará uma prioridade de selecção com o rato, mas o objecto requerido será muitas vezes anulado pelo mais alto, mas o que deseja ver imediatamente, sem entrar em sub-janelas como "Object Properties", etc. Afinal, quanto mais agradável for trabalhar com uma interface gráfica, mais claro é e menos tem de ser feito para descobrir algo ou para realizar uma manipulação final - intencional - com ela.
E porque não podemos comparar objectos? As linhas em diferentes TFs têm um preço definido. Portanto, compare o preço. Se os preços forem iguais, então trace a linha mais importante (na sua opinião). Esta será a priorização.
Para começar, gostaria de vos informar que, por exemplo, um objecto como a Linha Vertical não tem preço. Há apenas o tempo. Mas se ambas as linhas tiverem o mesmo tempo e forem definidas a partir de períodos de tempo diferentes, a linha do período mais novo pode ser definida por último e sobrepor visualmente a linha da mais velha. Claro que é possível nomear objectos (por exemplo, adicionando o nome do período de tempo ao fim do nome do objecto) e depois compará-los, mas pode ajudar, excepto na procura de objectos com pinagem, e não na ordem do seu posicionamento inicial.
Assim, por enquanto não há nada que estabeleça a prioridade de visibilidade de forma simples e bela à vontade do utilizador e não ao ditado de circunstâncias objectivas no mercado, além disso, em simultâneo, num mercado "aleatório" que ouve diferentes TFs.
Não se pode comparar os tempos?
Por não caber, esta propriedade relaciona-se com o aspecto de seleccionar um objecto gráfico com o rato, e não com a ordem em que é apresentado.
Então sugiro escrever um pedido ao RS, porque imho a ordem de selecção deve ser a mesma que a ordem de visualização - caso contrário é completamente contra-intuitiva. O que deve ser realçado é o que se encontra na "superfície". A ordem z deve estar lá para que os objectos possam "desvincular" a sua prioridade da ordem de criação.
O problema, tal como o entendo, é que uma linha está a bloquear a outra. É necessário estabelecer prioridades a fim de trazer a linha que é significativa (para si) para o primeiro plano. Se os tempos de todas as linhas são diferentes, então a prioridade não é importante, porque as linhas não se sobrepõem. Está interessado nos momentos em que as linhas se sobrepõem. Esse é o seu ponto de contagem - os tempos das linhas quando os tempos são os mesmos. Ou será que entendi mal o vosso problema?
Mais uma vez, o destaque é bom e a prioridade pode ser definida. A prioridade de renderização é má. E "a ordem de selecção deve corresponder à ordem de renderização" é uma conclusão duvidosa. A ordem de qualquer coisa não deve nada a ninguém por si só. Deve ser possível ao critério do utilizador definir qualquer prioridade a objectos que o exijam para fácil percepção/acesso/manipulação/etc. Talvez haja um esquisito que vive num mezanino e dorme com as barbatanas penduradas na cabeça - a ordem óbvia não funcionará para ele, mas para este esquisito, deveria haver também uma forma de ele definir qualquer objecto prioritário que considere mais lógico.
Porquê "outra vez"? Não o entende você mesmo? Sugeri uma versão funcional, a única lógica: a ordem z muda a ordem de selecção e visibilidade, porque ninguém pensaria em seleccionar algo que não é visível em condições normais. Se não for óbvio - vá em frente e tente promover "pesos", "prioridades" e outras características em falta.
Sugeri uma opção viável, a única lógica: a ordem z muda tanto a ordem de selecção como a visibilidade, porque ninguém pensaria em seleccionar algo que normalmente não é visível.
Os indicadores em cache em princípio não querem ser recalculados quando um parâmetro externo é alterado.
Exemplo Executo o indicador com o parâmetro A, obtenho os dados, altero o parâmetro de A para B, os dados não mudam, retiro o indicador.
Executar o indicador com o parâmetro B, os dados são os mesmos que os do parâmetro A.
Eu elimino o indicador, fecho o terminal, espero até o processo matar.
Terminal aberto, indicador de início com o parâmetro B de uma só vez.
Recebo (cálculo correcto para o parâmetro B) dados completamente diferentes.