Servicedesk : paresse, autisme ou refus d'admettre ses erreurs ? Compléter les graphiques avec des bougies non natives.
Est-ce la question que vous avez soulevée il y a un mois ? https://www.mql5.com/ru/forum/1111/page878#comment_344461
FiftyStars:
...L'histoire est ce qu'elle est. Nous n'avons pas d'histoire profonde. Pour votre commodité, l'historique plus profond est représenté par des barres quotidiennes.
Si cela ne vous convient pas, limitez manuellement l'utilisation de cet historique.
L'essentiel de la réponse était déjà connu à l'époque(https://www.mql5.com/ru/forum/1111/page878#comment_344518) :
Mais j'ai peur qu'elle (la réponse) soit quelque chose comme ceci : "Le programmeur lui-même peut calculer la date limite et limiter la profondeur de l'historique demandé.
J'ai contacté le Service Desk pour un problème d'attachement de bougies plus élevées à des graphiques à faible TF lorsqu'il n'y a pas d'historique sur les TF inférieurs. C'est-à-dire que lorsque nous allons au début de l'histoire dans le graphique M1, nous voyons des bougies non pas de M1, mais de D1, ou même de W1. En raison de cette adhésion, la fonction SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) renvoie non pas la date à laquelle l'historique M1 se termine, mais la date de la première barre en dehors du cadre temporel, c'est-à-dire que le cadre temporel spécifié n'affecte pas le résultat.
...
SERIES_BARS_COUNT renvoie le nombre de bougies (barres), appartenant à un certain symbole et à une certaine période de temps.
SERIES_FIRSTDATE renvoie la date de la première bougie (barre) ouverte, qui appartient à un certain symbole et à une certaine période de temps.
Plus d'informations
...
Les fonctions fonctionnent correctement.
Ce que vous voyez est une conséquence de votre demande de qualité antérieure.
L'histoire est ce qu'elle est. Nous n'avons pas d'histoire profonde. Pour votre commodité, l'historique plus profond est représenté par des barres quotidiennes.
Si cela ne vous convient pas, limitez manuellement l'utilisation de cet historique.
C'est une excuse franche, le programmeur ne peut pas prévoir toutes les variantes de l'histoire mordante, il ne peut donc pas prescrire la fonction de recherche de la première date du TF. Aujourd'hui ils sont comme ça, et demain ils auront de nouveaux rebondissements, et à l'insu de MQ, par exemple, le fait de dealer fera foirer quelque chose.
Et pourquoi en avons-nous besoin alors qu'il existe une fonction standard, mais le fait qu'elle donne la météo d'avant-hier est déjà un bug flagrant.
Voici le nœud du problème pour le programmeur :
Nous devons rechercher des variantes du critère selon lequel cette barre peut être considérée comme la première barre de la TF sélectionnée, et toutes les barres précédentes - l'ajout de la TF plus ancienne. Il peut y avoir des trous dans les barres, comme une barre manquée (c'est une conséquence directe du format d'enregistrement des barres choisi par MQ) ou des trous dans les barres comme un week-end ou un jour férié. Et dans une telle cacophonie de signes, il n'est pas clair comment déterminer que ce bar est le bon.
Quelle est l'essence du problème pour MQ : (si nous voulons dire qu'ils vont le résoudre)
En croisant les historiques de cryptage dans un fichier de données sur les points de convergence (ils ne sont pas nombreux, un maximum de 21 par le nombre de TF, en pratique, il y en a 2-3), le problème est résolu. Ensuite, écrivez une fonction pour lire ces informations protégées et les transmettre à l'utilisateur par requête.
Merci, ne décidez pas pour les commerçants.
Quelle tête fraîche était-ce pour faire un tel mouvement après vendredi - pour insérer les barres plus anciennes dans l 'échelle de tempsM1 ?
Qui vous a donné le droit - de renverser de nombreuses années de principes bien établis ?
Si vous n'êtes pas à l'aise avec cela, limitez l'utilisation de cette histoire manuellement.
Merci, ne décidez pas pour les commerçants.
Quelle tête fraîche était-ce pour faire un tel mouvement après vendredi - pour insérer des barres seniors dans l 'échelle de tempsM1 ?
Qui vous a donné le droit de renverser des principes établis depuis de nombreuses années ?
Alex, n'exagère pas, le collage des TF était nécessaire pour calculer correctement toutes les autres TF, après qu'ils aient décidé de calculer toutes les TF à partir de M1.
Si vous vous en souvenez, il nous a permis de calculer jusqu'à 21 TF (y compris les TF non standard).
On ne lui en a pas parlé plus d'une fois. Nous ne reviendrons pas à l'ancien système qui consistait à stocker chaque TF séparément, vous comprenez.
Mais le fait que l'implémentation ajoute plus de difficultés aux programmeurs est un fait. Et la question est simple à résoudre, mais non, nous savons mieux ce dont vous avez besoin :(
Alex n'exagère pas, le collage des TF était nécessaire pour calculer correctement toutes les autres TF, après que la décision ait été prise de calculer toutes les TF à partir de M1.
Le problème est résolu en définissant l'identifiant dans l'historique et lors de la lecture, si les données de la barre n'appartiennent pas à M1, alors ne pas sortir vers M1, n'appartiennent pas à M5, alors ne pas sortir vers M5. Ou oui... nous devrions écrire la date de jonction des barres de la période actuelle avec celles de la période supérieure dans FirstDate et l'utilisateur aura une réelle possibilité de savoir à partir de quelle date commencer le traitement afin de ne pas attraper les barres plus anciennes.
La situation est certainement débile.
Vous ne pouvez ni dessiner de tels graphiques, ni renvoyer de telles valeurs à partir de fonctions.
Vous voulez construire à partir de M1, construisez-le. Pas assez de M1 - trouver un moyen de s'en sortir, mais pas à nos dépens.
(tous adressés, bien sûr, à MQ)
- www.mql5.com
Je suis d'accord, c'est n'importe quoi.
Et s'il y a des séparateurs de points, c'est une beauté.
Et vous devez le tordre dans le code ((.
- 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
J'ai contacté le Service Desk pour un problème d'attachement de bougies plus élevées à des graphiques à faible TF lorsqu'il n'y a pas d'historique sur les TF inférieurs. Cela signifie que lorsque nous allons au début de l'histoire dans le graphique M1, nous voyons des bougies non pas de M1, mais de D1, ou même de W1. En raison de cette adhésion, la fonction SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) renvoie non pas la date à laquelle l'historique M1 se termine, mais la date de la première barre en dehors du cadre temporel, c'est-à-dire que le cadre temporel spécifié n'affecte pas le résultat. Lorsque j'ai posé la question, on m'a répondu que c'était pratique pour les utilisateurs et que la date limite pour chaque période de temps de chaque symbole devait être fixée manuellement. Excusez-moi, mais cette fonction ne devrait-elle pas être exécutée par la fonction SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x), et en quoiSERIES_FIRSTDATE diffère-t-elledeSERIES_FIRSTDATEdans le TF spécifié M1si le résultat est le même ?
Qu'est-ce que c'est que cette absurdité ? Qui et pourquoi cela convient-il ? Personne ne veut voir des bougies W1 sur des graphiques M1. Eh bien, sauf pour les masochistes ...
J'en arrive à la conclusion suivante : soit les développeurs sont autistes (ils vivent dans leur monde, où le dessus et le dessous sont la norme, ou plutôt pas la norme, mais le travail est à 5+), soit ils sont trop paresseux pour le corriger, soit le principe du "Comment se fait-il que nous n'ayons jamais tort, nous sommes tous bons". Il y a aussi des variantes : ils plaisantent, ils ne savent pas comment réparer.
Voici les captures d'écran, vous pouvez clairement voir la ligne de jonction de l'historique des différentes TF :
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
query 1 :
Version et débit binaire du terminal
Build 712 x86
Description du problème.
Les données historiques des petites échéances sont prolongées par les données historiques des grandes échéances. Cela signifie, par exemple, que l'historique de l'EURUSD sur M1 se termine le ~04.01.1999, et à gauche de celui-ci, attaché au graphique M1, se trouve le graphique D1 pour la période jusqu'au 04.01.1999.
Dans les captures d'écran ci-jointes, il est visible. De ce fait, la fonction SeriesInfoInteger avec le paramètre SERIES_FIRSTDATE ne fonctionne pas correctement. La fonction renvoie la première date de l'historique complet (y compris les périodes D1, W1 et MN1) au lieu de la première date de la période-symbole.
La séquence d'actions
Faire défiler le graphique jusqu'au début de l'histoire
Le résultat obtenu
Continuation du graphique avec des données historiques provenant d'horizons temporels plus larges.
Résultat attendu
Restriction du graphique à la fin des données de l'historique sur la période donnée.
Informations complémentaires
Demande 2 :
Version du terminal et débit binaire
construire 712 x86
Description du problème
Description dans la documentation :
NOMBRE DE BARRES DE SÉRIE.
Nombre de barres par période-symbole à l'heure actuelle
long
SÉRIE_PREMIÈRE DATE
La première date de la période de symbole actuelle.
datetime
En raison de l'accession à l'histoire pour le TF inférieur, dans le cas de l'absence d'histoire pour une période de temps spécifique sur le TF inférieur, et la présence d'histoire pour la même période sur le TF plus grand, le graphique, par exemple, M1 montre des bougies du graphique de D1.
Une solution à ce problème est-elle en préparation ? Existe-t-il actuellement des solutions à ce problème, autres que la restriction manuelle ?
Séquence d'actions
Utilisation de ces fonctions
Le résultat obtenu
SERIES_BARS_COUNT sur des horizons temporels bas (jusqu'à D1) renvoie le nombre de bougies (barres), appartenant au symbole et à l'horizon temporel, plus le nombre de bougies de l'horizon temporel supérieur le plus proche, pour lequel les données historiques sont disponibles.
SERIES_FIRSTDATE sur les échelles de temps basses (jusqu'à D1) renvoie la date d'ouverture de la première bougie (barre) de l'historique.
Le résultat attendu
SERIES_BARS_COUNT renvoie le nombre de bougies (barres), appartenant à un symbole et à une période de temps particuliers.
SERIES_FIRSTDATE renvoie la date de la première bougie (barre) ouverte, qui appartient à un symbole et à une période de temps spécifiés.
Plus d'informations
...
Les fonctions fonctionnent correctement.
Ce que vous voyez est une conséquence de votre demande de qualité antérieure.
L'histoire est ce qu'elle est. Nous n'avons pas d'histoire profonde. Pour votre commodité, l'historique plus profond est représenté par des barres quotidiennes.
Si cela ne vous convient pas, limitez manuellement l'utilisation de cet historique.