Erreurs, bugs, questions - page 519
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Donnez un exemple d'une des nombreuses tâches pour lesquelles une hiérarchisation multiple peut être nécessaire.
Il n'est pas très utile de dresser une liste d'exemples parce qu'il n'y en a peut-être pas beaucoup maintenant, mais de nombreuses tâches surviendront dans le processus de développement de tel ou tel code à l'avenir et s'accumuleront comme un problème et comme un autre exemple. Si vous ne demandez pas à le mettre en œuvre maintenant, vous en ressentirez le besoin dans six mois de toute façon.
Jusqu'à présent, dans cette veine, un seul problème, mais concret, a été soulevé : après le tracé en douceur des lignes éparses, il est impossible de supprimer manuellement les objets graphiques qui se chevauchent dans un ordre logique décroissant d'importance (l'importance est directement liée à l'ancienneté relative de chacun des délais) directement à partir d'un graphique, sans appeler la combo box"Liste des objets". J'aimerais qu'il en soit ainsi : en toutes circonstances, de manière programmatique (en fixant la propriété de priorité visuelle à une valeur nécessaire), les objets de différentes TF seraient regroupés parmi les objets similaires (c'est-à-dire pas nécessairement en se chevauchant, mais aussi en se serrant entre eux) par ordre croissant d'importance, de sorte que le plus haut serait le plus important, et qu'à l'analyse manuelle en ordre inverse, on pourrait obtenir l'ordre des moins importants. Et tout cela serait fait de manière scientifique, avec une programmation de la gradation séquentielle via les propriétés, et non pas avec des astuces comme qui a créé le plus tard et qui le surpasse (parce que dans les tâches de balisage graphique, il y a de nombreux cas où les objets de différentes TF sont générés non pas dans un ordre strict et droit, mais dans le désordre), ce qui conduit au chaos dans la primauté visuelle. Et même OBJPROP_ZORDER ne sera d'aucune aide ici, parce que le réglage programmatique de l'ordre d'accès à un objet ne fournira qu'une priorité de sélection avec la souris, mais l'objet requis sera souvent remplacé par le plus haut, mais ce que vous voulez voir immédiatement, sans aller dans les sous-fenêtres comme "Object Properties" etc. Après tout, plus il est agréable de travailler avec une interface graphique, plus elle est claire et moins il faut en faire pour découvrir quelque chose ou pour effectuer une dernière manipulation - volontaire - avec elle.
Et pourquoi ne pouvons-nous pas comparer des objets ? Les lignes sur les différents TF ont un prix défini. Comparez donc le prix. Si les prix sont égaux, tracez la ligne la plus importante (à votre avis). Il s'agira d'établir des priorités.
Pour commencer, je tiens à vous informer que, par exemple, un objet tel que la Ligne Verticale n'a pas de prix. Il n'y a que le temps. Mais si les deux lignes ont le même temps et qu'elles sont établies à partir d'horizons temporels différents, la ligne de l'horizon temporel le plus récent pourrait être établie en dernier et chevaucher visuellement la ligne de l'horizon temporel le plus ancien. Bien sûr, il est possible de nommer les objets (par exemple, en ajoutant le nom de l'horizon temporel à la fin du nom de l'objet) et de les comparer ensuite, mais cela ne peut servir que pour la recherche des objets épinglés, et non dans l'ordre de leur positionnement initial.
Donc, pour l'instant il n'y a rien pour fixer la priorité de visibilité simplement et superbement à la volonté de l'utilisateur et non pas à la dictée de circonstances objectives sur le marché, de plus à l'écoute simultanée "aléatoire" du marché de différents TFs.
Vous ne pouvez pas comparer les temps ?
Parce qu'elle ne convient pas, cette propriété se rapporte à l'aspect de la sélection d'un objet graphique avec la souris, et non à l'ordre dans lequel il est rendu.
Ensuite, je suggère d'écrire une requête au SR, parce qu'à mon avis l'ordre de sélection devrait être le même que l'ordre de visualisation - sinon c'est complètement contre-intuitif. Ce qu'il faut souligner, c'est ce qui se trouve à la "surface". Le zorder est censé être là pour que les objets puissent "délier" leur priorité de l'ordre dans lequel ils sont créés.
Le problème, tel que je le comprends, est qu'une ligne bloque l'autre. Vous devez établir des priorités afin de mettre au premier plan la ligne qui est importante (pour vous). Si les temps de toutes les lignes sont différents, alors la priorité n'est pas importante car les lignes ne se chevauchent pas. Vous êtes intéressé par les moments où les lignes se chevauchent. C'est votre point de comptage - les temps des lignes quand les temps sont les mêmes. Ou ai-je mal compris votre problème ?
Là encore, la mise en évidence est bonne et la priorité peut être définie. La priorité de rendu est mauvaise. Et "l'ordre de sélection devrait correspondre à l'ordre de rendu" est une conclusion douteuse. L'ordre des choses ne doit rien à personne par lui-même. Il devrait être possible, à la discrétion de l'utilisateur, de donner la priorité aux objets qui en ont besoin pour faciliter la perception, l'accès, la manipulation, etc. Peut-être qu'il y a un cinglé qui vit sur une mezzanine et dort avec ses nageoires qui pendent de sa tête - l'ordre évident ne fonctionnera pas pour lui, mais pour ce cinglé, il devrait aussi y avoir un moyen de définir l'objet prioritaire qu'il considère le plus logique.
Pourquoi "encore" ? Tu ne comprends pas toi-même ? J'ai proposé une version de travail, la seule logique : zorder change l'ordre de sélection et de visibilité, car personne ne penserait à sélectionner quelque chose qui n'est pas visible dans des conditions normales. Si ce n'est pas évident - allez-y et essayez de promouvoir les "poids", les "priorités" et autres fonctionnalités manquantes.
J'ai proposé une option réalisable, la seule logique : zorder change à la fois l'ordre de sélection et la visibilité, car personne ne penserait à sélectionner quelque chose qui n'est pas normalement visible.
En principe, les indicateurs mis en cache ne doivent pas être recalculés lorsqu'un paramètre externe est modifié.
Exemple je lance l'indicateur avec le paramètre A, j'obtiens les données, je change le paramètre de A à B, les données ne changent pas, je supprime l'indicateur.
Exécutez l'indicateur avec le paramètre B, les données sont les mêmes que celles du paramètre A.
Je supprime l'indicateur, je ferme le terminal, j'attends que le processus se termine.
Ouvrir le terminal, démarrer immédiatement l'indicateur avec le paramètre B.
J'obtiens (calcul correct pour le paramètre B) des données complètement différentes.