Générateur d'ID unique pour un indicateur particulier - page 2
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
Quel est le problème avec le numéro de sous-fenêtre ?
Je ne sais pas à quoi vous pensez mais, lors de l'application d'un modèle ou d'un rechargement, une valeur telle que CHART_WINDOWS_TOTAL est rapportée comme le total des indicateurs sur le graphique, et non le total chargé jusqu'à présent (c'est-à-dire qu'elle n'augmente pas un par un à mesure que chaque indicateur est initialisé).
Quel est le problème avec le numéro de sous-fenêtre ?
Avec les 610/614 il était presque impossible de le récupérer correctement à partir de l'indicateur lui-même, dans le 616 c'est presque résolu, mais il échoue toujours dans DeInit().
Avec les 610/614 il était presque impossible de le récupérer correctement à partir de l'indicateur lui-même, dans le 616 c'est en grande partie corrigé, mais il échoue toujours dans DeInit().
ChartWindowFind() semble fonctionner pour moi. De toute façon, ce n'est pas fiable, car si vous supprimez un indicateur puis en ajoutez un autre, le numéro de la sous-fenêtre est modifié.
Même problème avec ChartWindowFind() qu'avec l'ancienne WindowFind() : c'est inutile s'il y a plus d'une instance du même indicateur, par exemple deux fenêtres RSI montrant des calculs pour des périodes différentes.
C'est ce que j'ai dit, peu fiable.
C'est un problème intéressant. Comme je pense qu'il n'est logique d'ajouter le même indicateur plusieurs fois que lorsque vous utilisez différents paramètres d' entrée, une solution serait de former une signature à partir de ces paramètres. Ou, bien sûr, l'une des solutions que vous avez proposées précédemment.
Même problème avec ChartWindowFind() qu'avec l'ancienne WindowFind() : c'est inutile s'il y a plus d'une instance du même indicateur, par exemple deux fenêtres RSI montrant des calculs pour des périodes différentes (ou la même période, mais des changements dans d'autres paramètres qui ne sont pas reflétés dans un appel à IndicatorShortName).
En fait ChartWindowFind fonctionne déjà pour les indicateurs en 616, sauf le OnDeinit. Mais encore trop humide pour être considéré comme stable, donc je préfère l'éviter dans toute création d'ID.
Merci pour votre contribution, je vais choisir soit le verrouillage du fichier, soit l'attente du changement de GetTickCount. Je dois faire un essai.
C'est ce que j'ai dit, peu fiable.
C'est un problème intéressant. Comme je pense qu'il n'est logique d'ajouter le même indicateur plusieurs fois que lorsque vous utilisez différents paramètres d'entrée, une solution serait de former une signature à partir de ces paramètres. Ou, bien sûr, l'une des solutions que vous avez proposées précédemment.
En fait ChartWindowFind fonctionne déjà pour les indicateurs en 616, sauf le OnDeinit. Mais encore trop humide pour être considéré comme stable, donc je préfère l'éviter dans toute création d'ID.
Merci pour votre contribution, je vais choisir entre le verrouillage du fichier ou l'attente du changement de GetTickCount. Je dois faire un essai.
En lisant ceci, j'ai appris à utiliser le temps comme GetTickCount ci-dessus.
Ensuite, j'ai appris à utiliser la date et l'heure de compilation du fichier __DATETIME__.
https://docs.mql4.com/constants/namedconstants/compilemacros
Qu'est-ce que vous en pensez ?
Je ne suis pas sûr que vous vouliez dire "enseigné".
J'en utilise quelques-uns pour le débogage, mais pour __DATETIME__ je n'ai pas encore trouvé d'utilité... où voulez-vous en venir ?