Erreurs, bugs, questions - page 2101
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
quelle mise à jour est arrivée, 1736, qu'est-ce qu'elle contient, où puis-je la lire ?
Je propose de donner la possibilité de déterminer par programme quel indicateur tampon est dessiné sur le graphique.
Supposons qu'un trader crée ses propres indicateurs, nous ne savons pas combien de tampons sont utilisés pour le calcul et combien sont utilisés pour dessiner l'indicateur sur le graphique.
Traiter les indicateurs personnalisés par
intChartIndicatorGet(
longchart_id,// identifiant du graphique
intsub_window// numéro de la sous-fenêtre
const string indicator_shortname // nom court de l'indicateur
) ;
Nous pouvons également demander le tableau des tampons de dessin
intChartIndicatorGet(
longchart_id,// identifiant du graphique
intsub_window//numéro de la fenêtre
const string indicator_shortname // nom court de l'indicateur
int & IndicatorVisualBuffer[] // numéros des tampons de dessin... ) ;
Cela permettra d'étendre la possibilité de travailler avec des indicateurs inconnus installés sur le graphique...
Je propose de donner la possibilité de déterminer par programme quel indicateur tampon est dessiné sur le graphique.
Supposons qu'un trader lance ses indicateurs, nous ne savons pas combien de tampons sont utilisés pour calculer et combien sont utilisés pour dessiner l'indicateur sur le graphique.
Adressage à l'indicateur via
intChartIndicatorGet(
longchart_id,// ID du graphique
intsub_window// numéro de la sous-fenêtre
const string indicator_shortname // nom court de l'indicateur
) ;
Nous pouvons également demander le tableau des tampons de dessin
intChartIndicatorGet(
longchart_id,// identifiant du graphique
intsub_window//numéro de la fenêtre
const string indicator_shortname // nom court de l'indicateur
int & IndicatorVisualBuffer[] // numéros des tampons de dessin... ) ;
Cela augmentera la possibilité de travailler avec des indicateurs inconnus installés dans le graphique...
Qu'est-ce que ça rapporte ?
et quelle sera l'utilité de l'ajouter ? Vous voulez ajouter un paramètre d'entrée et recevoir le même manche d'indicateur en réponse...
Et si ça ne vous dérange pas, dans quel but en avez-vous besoin ? Je ne suis pas ironique. Après tout, si quelque chose est suggéré, vous devriez, à mon avis, donner un argument convaincant de la nécessité de la suggestion.
Que retourne-t-il ?
et à quoi cela servirait-il de l'ajouter ? Vous proposez d'ajouter un paramètre d'entrée et d'obtenir le même manche d'indicateur en réponse...
Et si ce n'est pas difficile, dans quel but une telle nécessité est-elle apparue ? La question est sans ironie. Après tout, si l'on offre quelque chose, il est nécessaire, à mon avis, de donner des arguments convaincants en faveur de la nécessité de l'offre.
L'utilisateur met n'importe quel indicateur.
Le conseiller expert le trouve automatiquement et utilise les données tampons pour recevoir le signal.
Maintenant nous devons utiliser iCustom et si nous pouvons ajouter une liste de paramètres, voici le problème avec les tampons....
Il est possible de compter la quantité de tampons par le biais de Copy, mais pour comprendre lequel il est impossible ...
L'utilisateur place n'importe quel indicateur.
Le conseiller expert le trouve automatiquement et utilise les données tampons pour obtenir le signal.
Maintenant, nous devons utiliser iCustom et si nous pouvons écrire la liste des paramètres, voici le problème avec les tampons.....
Il est possible de compter la quantité de tampons en utilisant Copy de manière programmatique, mais il est impossible de comprendre lequel d'entre eux dessine ...
Pourquoi est-ce impossible ? Le tampon INDICATOR_CALCULATIONS peut-il être retiré par iCustom() ?
C'est une question intéressante, mais ce n'est pas le moment d'en discuter dans ce fil. Personnellement, je doute qu'elle puisse améliorer ou simplifier d'une manière ou d'une autre le travail du programmeur. Les indicateurs sont trop différents et les conditions de leur application sont trop différentes. Ensuite, nous devrons demander à pouvoir déterminer le type de tracé graphique et d'autres choses encore, et nos demandes internes feront boule de neige.
Pourquoi n'est-ce pas possible ? Le tampon INDICATOR_CALCULATIONS peut-il être atteint par iCustom() ?
La question est intéressante, mais ce n'est pas le moment d'en discuter dans ce fil. Personnellement, je doute qu'il puisse améliorer ou faciliter le travail du programmeur. Il y a trop d'indicateurs différents et trop de conditions différentes pour leur application. Ensuite, nous devrons demander à pouvoir déterminer le type de tracé graphique et d'autres choses encore, et nos demandes internes feront boule de neige.
Théoriquement, ce qui est écrit dans l'indicateur par défaut, je ne parle pas du code du programmeur, devrait être disponible de l'extérieur ... Les tampons ont leur nombre, leur type de tracé, leur couleur et d'autres standards ...
C'est le problème que j'ai rencontré :
J'ai décidé d'utiliser comme magie le reste de la division de ChartID par 1000 ou 10000, cela n'a pas vraiment d'importance.
Mais pour une raison quelconque, avec des ChartID() différents, le reste de la division est soudainement le même. Question : pourquoi ?
Vérification du script
Résultat
Je m'attendais à voir 74907 et 74908 respectivement, car le reste de la division devrait être le même.
J'attends également une réponse à cette question.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Bugs, bugs, questions
Alexey Viktorov, 2018.01.09 14:21
Dans le testeur MT5, l'objet OBJ_EDIT "Input field" ne permet pas d'éditer une valeur. Est-ce la façon dont il est conçu ou est-ce un bug ?
Dans les terminaux et dans le testeur MT4, il est modifiable, mais dans le testeur MT5, il ne veut pas l'être, la valeur saisie par programme lors de la création de l'objet disparaît complètement.
Mais pour une raison quelconque, un ChartID() différent produit soudainement le même résidu de division. Question : pourquoi ?
Parce que l'entrée fmod est double. Double ne peut pas stocker un grand nombre d'entiers. Par exemple, voici votre cas :
Faites-le.
En prenant l'exemple de float, vous pouvez rapidement comprendre la particularité de double
Résultat
SZY double ne perd pas l'information de l'ensemble de la gamme intérieure, ce qui n'est pas le cas avec long.
Parce que l'entrée fmod est double. Double ne peut pas stocker un grand nombre d'entiers. Par exemple, votre affaire :
Faites-le.
Bien sûr, je vais vérifier cet échantillon maintenant mais j'avais aussi un code de vérification comme celui-ci
le résultat est
Il indique qu'il ne doit pas y avoir de troncature de la valeur.
Mais ici, j'ai vérifié cette variante et j'ai légèrement modifié la proposition.
et j'ai obtenu la variante attendue.
Une autre question apparaît,
Si MathMod ainsi que fmodrenvoie le reste réel après la division de deux nombres. Et % selon la documentation
Le reste des minutes = temps % 60;
pourquoi y a-t-il une différence ?
pourquoi cette différence ?
La réponse est la même.