Nous ne pouvons plus contrôler le placement des objets sur le graphique "verticalement".
.
Je suis pour 2) ou au moins 1)
Et celle de la procédure, qui sait ?
Je propose également ma propre variante
tout en faveur des feuilles de style en cascade !!!!!
Ouais, tu es dans le MKL5, beaucoup de "super".
2)
Le fait que l'ordre des objets soit déterminé par le moment de leur création n'est qu'un inconvénient pour le mappage.
sans ambiguïté - il s'agit d'un oubli et d'une méconnaissance du problème de la part des métacitations.
Après tout, dans le cas du tri par nom, le programmeur a au moins la possibilité de trier à sa guise,
alors qu'avec la date de création, même cette possibilité a disparu.
Vous devriez rendre le 1 ou mieux le 2. Il ajoute simplement une autre propriété pratique à l'objet.
Bien sûr, pour la coordonnée Z, c'est dans l'esprit de la POO.
Je suis pour 2).
2) - Meilleur choix.
1. On peut, bien sûr, discuter des fonctionnalités non documentées. Et cela a été fait à de nombreuses reprises. Mais afin de trouver des solutions. Pas pour modifier un comportement non documenté.
2. Nous avons reçu beaucoup plus de demandes (plus que de participants à cette discussion) pour changer la façon dont les objets sont rendus. Oui, dans Five, nous avons établi un ordre simple et naturel en fonction de l'heure de création de l'objet (cependant, cela n'est pas documenté). Que faisons-nous maintenant ?
3. nous ne faisons rien ! Car avec le tri actuel, nous pouvons simplement recréer un groupe d'objets, ce qui était impossible avec le tri par nom.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
La dernière discussion, presque scandaleuse, sur le problème du formatage du code source s'est terminée par la reconnaissance par les développeurs du "droit" du programmeur d'écrire les programmes comme il le souhaite (et non comme il le pense) et par la promesse de finaliser les paramètres de formatage du code source.
J'ai maintenant rencontré une situation similaire et je veux à nouveau demander l'avis de ceux pour qui ils développent MQL5.
Commencez ici. En bref, l'histoire est la suivante : les objets de MQL5 sont placés dans un tableau dans l'ordre de leur création. Le premier objet créé est le plus bas. Si vous le supprimez accidentellement dans le code ou par un utilisateur, aucun autre moyen de le déposer ne sera possible (sauf à supprimer les objets restants et à les recréer dans le bon ordre). L'exemple le plus évident : vous avez créé un substrat pour y placer des textes, des champs de saisie et des boutons. Si vous le supprimez maintenant et que vous le créez, il couvrira tout ce que vous souhaitez voir au-dessus de lui comme le plus récent.
J'ai demandé au Service Desk de me faire une suggestion.
необходимо предусмотреть механизмы произвольной сортировки объектов "по вертикали". Либо наличием свойства Zorder у каждого объекта, либо функциями BringToFront, SendToBack, InFrontOf, BehindOf. Ну или хотябы сделайте так же как было в 4-ке - по имени объекта, т.к. к такому поведению объектов все уже привыкли и ожидают что в 5-ке будет также.
Je l'ai eu tout de suite à....
La règle de séquence de tirage actuelle est simple et suffisante pour le contrôle du tirage. Dans certains cas, le tri par nom permet un contrôle plus souple de la séquence de rendu - solution simple pour la tâche spécifique décrite dans ce forum (petit inconvénient), mais qui obligera tous les utilisateurs à tenir compte du nom lors de l'ajout de tout objet (y compris les objets non-MQL) (gros inconvénient).
La séquence de rendu lors de la superposition des objets dans MT5 est déjà utilisée dans la pratique (arrière-plan, boutons, etc.). Je ne me suis pas plaint de problèmes - tout est résolu de manière tout à fait simple et algorithmique.
qui aurait douté que pour eux c'est, pour ainsi dire, une solution "simple et suffisante pour contrôler le rendu" ? ! :))))
à mon commentaire :
ForexTools :
ce n'est pas parce que les autres ne se sont pas plaints qu'il n'y a pas de problème, peut-être parce que personne ne s'est occupé de l'interface ;)
Je traîne dans le coin :
https://www.mql5.com/ru/articles/64
https://www.mql5.com/ru/articles/65
https://www.mql5.com/ru/code/68
Nous avons effectué de nombreux tests internes, nous avons développé des interfaces et des jeux. Il n'y a pas de problème en tant que tel avec l'ordre de rendu, il suffit de modifier votre approche en tenant compte de cet ordre.Bon argument : les jeux Ttris et Miner ont été utilisés pour déboguer des solutions pour les futures interfaces commerciales :))))
Et la ligne de fond est leur verdict :
J'ai décrit plus haut, de manière assez détaillée, la raison pour laquelle nous ne ferons pas de changements. Je le répète en résumé : pour des raisons de commodité dans un cas particulier, vous ne pouvez pas rendre la vie plus difficile à tous les autres dans tous les autres cas.
Si dans F4 il y avait au moins un certain ordre de localisation des objets du graphique (par les noms d'objets), dans 5 on a fait un jeu de cartes auto-tiré et suggéré de "changer notre approche" pour écrire des programmes MQL5.
TOTAL : que pensent les autres codeurs ? Avez-vous besoin d'un mécanisme pour contrôler le placement vertical des objets ? J'ai proposé trois options :
1) ancien - par des noms d'objets
2) normal - en ajoutant la propriété d'ordre Z à chaque objet du graphique
3) procédural - utilisation des fonctions BringToFront, SendToBack, InFrontOf, BehindOf.
ou accepter la seule option proposée par les développeurs : en cas de suppression, redessiner complètement tous les objets ( !!!!) dans l'ordre requis.
Qui a une idée sur ce sujet ?