Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Nulle part sans toi - 6. - page 1038

 
nikelodeon:

La différence est significative, mais WHY !!!!!.

La différence peut provenir d'un appel à des moments différents ou d'une différence dans les paramètres d'appel. Et l'appel supplémentaire... Nous avons eu un cas similaire récemment. Nous avons un T qui est censé être déclenché par un appel. Mais la sonnette avait deux boutons : le bon pour notre patron et un supplémentaire pour Skunk du département voisin. Le patron a trouvé le fil, l'a coupé et a dit à Scoon : "Soit tu commences ta propre N, soit tu la déclenches toi-même. Quelle copie ? Terminé ! !!
 
Tema97:
indicateur personnalisé - valeur de retour - comment ?
iCustom - Renvoie la valeur de l' indicateur personnalisé spécifié.
 
LRA:
La différence peut provenir d'un appel à des moments différents ou d'une différence dans les paramètres d'appel. Et l'appel supplémentaire... Nous avons eu un cas similaire récemment. Notre T est censé être déclenché par l'appel. Mais la sonnette avait deux boutons : le bon pour notre patron et un supplémentaire pour Skunk du département voisin. Le patron a trouvé le fil, l'a coupé et a dit à Scoon : "Soit tu commences ta propre N, soit tu la déclenches toi-même. Quelle copie ? Terminé ! !!
Hardly...... L'appel se fait sur chaque barre, la procédure stat compte la même chose seulement quand un nouveau signal apparaît, et quand je n'appelle rien avec custome, le commentaire dans l'indicateur principal écrit la valeur correctement, dès que l'indicateur est appelé, avec custome, tout... threndetz.....
 
Bonjour, a rencontré un problème, quelqu'un peut-il suggérer, le problème avec la fixation du prix pour les ordres sur les cinq chiffres, l'essence du problème : le prix actuel est stocké dans une variable pour le calcul ultérieur de l'installation de l'ordre en attente, en conséquence ouvre l'ordre à 1,00000, je pense que la question est l'arrondissement, NormalizetoDouble ne pas aider. De plus, lors de la sortie sur imprimante, on a remarqué que l'asc et l'enchère sont arrondis au quatrième chiffre. Si nous faisons quelque chose comme cask=ask*100000 , le résultat est normal (123456 à 1.23456), mais quand on divise dans la direction opposée, l'image se répète
 
STiZ:
Bonjour, a couru dans un problème, quelqu'un peut-il suggérer, le problème avec la fixation du prix pour les ordres sur les cinq chiffres, l'essence du problème : le prix actuel est stocké dans une variable pour le calcul ultérieur de l'installation de l'ordre en attente, en conséquence ouvre l'ordre à 1,00000, je crois que la question est l'arrondissement, NormalizetoDouble ne pas aider. De plus, lors de la sortie sur imprimante, on a remarqué que l'asc et l'enchère sont arrondis au quatrième chiffre. Si vous faites quelque chose comme cask=ask*100000 , le résultat est normal (123456 à 1.23456), mais quand on divise dans la direction opposée, l'image se répète
Où est le code ?
 
Bonjour à tous !!!!! Je travaille sur une lykbase et voici donc la question. Combien d'indicateurs peuvent être appelés dans un indicateur avec la fonction IKustom ????. J'appelle les valeurs de 16 autres indicateurs dans mon indicateur et elles sont utilisées dans le calcul. Mais quand j'appelle l'indicateur sur un graphique, il dit quelque chose comme "blah, blah, blah l'indicateur est trop lent, veuillez réécrire l'indicateur". Donc la question est : combien d'Ikustom le terminal va-t-il tirer ?
 
nikelodeon:
Bonjour à tous !!!!! Je travaille sur une lykbase et voici donc la question. Combien d'indicateurs peuvent être appelés dans un indicateur avec la fonction IKustom ????. J'appelle les valeurs de 16 autres indicateurs dans mon indicateur et elles sont utilisées dans le calcul. Mais quand j'appelle l'indicateur sur un graphique, il dit quelque chose comme "blah, blah, blah l'indicateur est trop lent, veuillez réécrire l'indicateur". D'où la question : combien d'Ikustom le terminal va-t-il tirer ?
Il fonctionnera plus rapidement si tous les indicateurs d'iCustom sont rassemblés dans le Conseiller Expert et si toutes les combinaisons possibles de calculs sont effectuées dans celui-ci. Les indicateurs calculent sans arrêt, ce qui ralentit les calculs, tandis que le conseiller expert calcule uniquement par ticks et effectue tous les calculs en un instant. C'est toujours plus rapide et plus économique !
 
borilunad:
Tout fonctionnera plus rapidement si tous les indicateurs iCustom sont rassemblés dans le conseiller expert et si toutes sortes de combinaisons de calculs sont effectuées dans celui-ci. Alors que les indicateurs calculent en continu, le conseiller expert ne calcule que les ticks et effectue tous les calculs en un instant. C'est toujours plus rapide et plus économique !

Vous avez dit ....

Les indicateurs ne comptent l'historique complet (ou la quantité qui leur est permise) qu'au moment du démarrage, du changement de cadre temporel, du chargement de l'historique, et si le codeur lui-même a fixé la condition de recalcul de l'ensemble du tableau par une certaine condition. A d'autres moments, l'indicateur ne calcule que la barre actuelle ou deux ou trois nouvelles barres (si le programmeur l'a prévu). La même chose qu'avec l'EA quand le tick arrive, et l'indicateur ne saute pas de ticks, comme le fait l'EA (les ticks peuvent arriver par paquets et l'EA ne recevra que le dernier, contrairement à l'indicateur qui les reçoit tous).

Alors ne trompez pas les gens, Boris.

Au lieu de iCustom(), il suffit de transférer les calculs des autres indicateurs dans un seul qui calculera tout lui-même.

 
En bref : si vous voulez que ce soit bien fait, faites-le vous-même.
 
tara:
En bref : si vous voulez bien faire les choses, faites-les vous-même.
Et si vous échouez, ce n'est pas grave ! C'est le processus qui compte, et le résultat peut ne pas être satisfaisant. ;)