La table de tous les métiers. Accès via MQL5 - page 3
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
Quelqu'un sait-il quelle est l'erreur ?
L'indicateur fonctionne correctement, mais plus de barres sont affichées,
que ce pour quoi il a été conçu.
Je n'ai pas regardé le code, mais je suppose qu'après l'apparition de chaque nouvelle barre, il ne prend pas en compte le fait que les lignes de l'indicateur sont aussi automatiquement décalées vers la gauche (si vous regardez le graphique). En d'autres termes, lorsqu'une nouvelle barre apparaît, déplacez les lignes de l'indicateur vers la droite (lorsque vous regardez le graphique).
La touche finale...
Il s'avère que ce n'est pas le dernier ....
Il faut encore l'optimiser.
Je vais le terminer et le tester...
Si c'est le cas, conservez l'indicateur tick - indicateur d'intérêt ouvert (exécuté sur un compte réel connecté à la bourse).
Un problème sérieux a été découvert :
Ticks en double avec une heure de début différente :(
l'heure de début est différente et les ticks sont copiés de manière répétée si
ils ont la même heure
Je le décrirai en détail demain.
Dernière version
Je n'arrive pas à dormir, alors j'ai pensé que je devais écrire ce qui se passe.
(Le code complet de l'indicateur est dans le post ci-dessus).
Les ticks de la bourse ne parviennent pas au terminal selon des intervalles de temps stricts,
mais en blocs (voir capture d'écran) Bloc 1, Bloc 2 etc.
Le terminal les "stocke" et les affiche dans le tableau, au fur et à mesure qu'il les reçoit de la bourse (bloc par bloc).
Dans lesdeux blocs, il peut y avoir des transactions avec la même heure.
Si nous appelons CopyTicks() PAS en temps réel (disons le jour suivant ou quelques secondes),
alors la fonction CopyTicks() retournera les données exactes.
Mais en temps réel, il se passe ce qui suit :
Si start_time = (23:49:58.114), nous obtenons le bloc 1 complet (entouré en rouge).
Ensuite, nous attendons le changement d'heure pour obtenir le bloc 2 (entouré en vert).
Pour éviter de dupliquer le bloc 1 (OnBookEvent peut se déclencher très rapidement)
nous introduisons une vérification que l'heure a changé
if(start_time==ulong(ticks[copied-1].time_msc)) return;
Lorsque start_time = (23:49:58.596), nous aurions dû obtenir le bloc 2,
mais la fonction CopyTicks() renvoie à la fois le bloc 2 et tous les ticks avec l'heure (23:49:58.114),
si le bloc 2 a au moins un tick avec la même heure (23:49:58.114).
C'est une bien triste nouvelle.... :(
À moins que les développeurs ne corrigent ce problème, il est impossible d'obtenir la bande en temps réel des transactions.
Et pourquoi pensez-vous que les ticks sont téléchargés à partir d'un moment donné et du FUTUR vers l'histoire lorsque vous interrogez par le temps ? En fait, lorsque vous demandez des ticks par heure, les ticks sont téléchargés à partir d'une heure donnée et dans le FUTUR. Par exemple :
Données d'entrée (demande 20000 ticks), temps 2016.08.25 20-00-00:
Recevez :
C'est-à-dire que les ticks sont reçus à partir de l'heure demandée2016.08.25 20:00:00 vers le FUTUR (le dernier tick a l'heure2016.08.26 00:02:08).
Et pourquoi pensez-vous que les ticks sont téléchargés à partir d'un temps donné et FUTUR vers l'historique lors d'une requête par temps ? En fait, lorsque vous demandez des ticks par heure, les ticks sont téléchargés à partir d'une heure donnée et dans le FUTUR. Par exemple :
Données d'entrée (demande 20000 ticks), temps 2016.08.25 20-00-00:
Recevez :
C'est-à-dire que les ticks sont reçus à partir de l'heure demandée2016.08.25 20:00:00 vers FUTUR (le dernier tick a l'heure2016.08.26 00:02:08).
Je ne pense pas en profondeur, je vois "plaqué" de la profondeur.
Pourquoi penser ?
Lancez l'indicateur et voyez par vous-même !
Et lisez-vous seulement ce qui est écrit ?