Erreurs, bugs, questions - page 3032

 

Je voudrais vous rappeler.

1. Pour chaque symbole, pour lequel au moins un graphique est ouvert, il y a un thread séparé pour traiter les ticks entrants. Plusieurs graphiques pour un même symbole peuvent être ouverts, mais il n'y aura toujours qu'un seul fil.

2. Le fil de symboles ne traite pas les graphiques, mais les séries chronologiques. C'est-à-dire, les mêmes tableaux de données, qui sont soumis à la requête CopyRates.

3. il est inutile de demander à votre symbole dans OnTick ou OnCalculate, s'il est synchronisé. Bien sûr qu'elle l'est !

4. Toutes les séries chronologiques sont traitées dans l'ordre, du plus bas au plus haut. D'abord nous appliquons le tick, et ensuite le calcul de tous les indicateurs, créés sur cette timeseries. Si vous demandez des données pour le même symbole H1 à l'indicateur, qui travaille sur M1, vous n'obtiendrez jamais de données avec le tick appliqué. Les données seront toujours en retard d'un tick, peu importe les astuces que vous appliquerez. Parce qu'il y a un fil par symbole avec un traitement consécutif dans le temps.

5. La déclaration précédente ne s'applique pas aux EA et aux scripts, car ces derniers fonctionnent chacun dans leur propre fil conducteur.

 
Slava:

Je voudrais vous rappeler.

1. Pour chaque symbole, pour lequel au moins un graphique est ouvert, il y a un thread séparé pour traiter les ticks entrants. Plusieurs graphiques pour un même symbole peuvent être ouverts, mais il n'y aura toujours qu'un seul fil.

2. Le fil de symboles ne traite pas les graphiques, mais les séries chronologiques. C'est-à-dire, les mêmes tableaux de données, qui sont soumis à la requête CopyRates.

3. il est inutile de demander à votre symbole dans OnTick ou OnCalculate, s'il est synchronisé. Bien sûr qu'elle l'est !

4. Toutes les séries chronologiques sont traitées dans l'ordre, du plus bas au plus haut. Nous appliquons d'abord le tick, puis le calcul de tous les indicateurs, créés à cette série temporelle. Si vous demandez des données pour le même symbole H1 à l'indicateur, qui travaille sur M1, vous n'obtiendrez jamais de données avec le tick appliqué. Les données seront toujours en retard d'un tick, peu importe les astuces que vous appliquerez. Parce qu'il y a un fil par symbole avec un traitement consécutif dans le temps.

5. La déclaration précédente ne concerne pas les conseillers-experts et les scripts, car les conseillers-experts et les scripts fonctionnent dans leurs propres fils séparés.

Veuillez m'envoyer des rappels plus détaillés comme celui-ci ! Merci !

 
Slava:

Je voudrais vous rappeler.

4. Toutes les séries chronologiques sont traitées dans l'ordre, du plus bas au plus haut. D'abord l'application tick, puis le calcul de tous les indicateurs créés sur cette série temporelle. Si vous demandez des données pour le même symbole H1 à un indicateur, travaillant sur M1, vous n'obtiendrez jamais de données avec un tick appliqué. Les données seront toujours en retard d'un tick, peu importe les astuces que vous appliquerez. Parce qu'il y a un fil par symbole avec un traitement consécutif dans le temps.

5. La déclaration précédente ne s'applique pas aux EA et aux scripts, car ces derniers fonctionnent chacun dans leur propre fil.

Est-ce que je comprends bien que si un EA fonctionnant sur M1 utilise un indicateur sur M1 (ou tout autre TF ?) qui prend des données du TF supérieur, alors au premier tick d'une nouvelle barre il ne pourra de toute façon pas retourner la valeur réelle, parce que la file d'attente pour calculer le TF supérieur l'atteindra après n ticks ?

J'ai simplement été confronté à ce comportement et j'ai cherché un problème dans l'indicateur, et il s'avère maintenant qu'il devrait en être ainsi. Mais si c'est le cas, cela interfère fortement avec les tests car je dois sauter certains ticks, ce qui est critique lorsque l'on teste en mode OHLC.

 
Slava:

2. Symbol stream ne traite pas les graphiques, mais les séries temporelles. C'est-à-dire que les tableaux de données qui sont donnés à la requête CopyRates

....

4. Toutes les séries chronologiques sont traitées dans l'ordre, du plus bas au plus haut. D'abord l'application du tick, puis le calcul de tous les indicateurs, créés sur cette série temporelle. Si vous demandez des données pour le même symbole H1 à un indicateur, travaillant sur M1, vous n'obtiendrez jamais de données avec un tick appliqué. Les données seront toujours en retard d'un tick, peu importe les astuces que vous appliquerez. Parce qu'il y a un fil par symbole avec un traitement consécutif dans le temps.

Pourquoi j'obtiens des écrans noirs de "mise à jour" lorsque je change de TF ?

j'ai ouvert le graphique que j'utilisais avant (H1 sur EURUSD), j'ai laissé l'indicateur, je n'ai rien fait pendant 2-3 minutes, puis je suis passé à un graphique inférieur (M30...M1), l'écran noir "Update" peut apparaître pendant 10 secondes

et cet écran noir dépend du build - quand le terminal n'a pas d'écran noir, et quand cela m'ennuie vraiment, parce que vous savez avec certitude que l'historique est chargé, vous avez juste besoin de rendre un graphique au terminal, et pourquoi vous attendez cet écran noir


Par exemple, si l'indicateur fonctionne sur M5 et que toutes les 30 minutes, il est appelé sur H1, est-ce que CopyBuffer() obtiendra toujours les données correctes de H1 ?

ou pas un fait, donc "tirer l'indicateur" sur H1 à chaque tick(la rupture de la connexion n'est pas encore considérée)

 

comment gérer les variables d'une boucle/fonction dans une autre fonction ?

la visibilité peut-elle être rendue plus globale ?

 
Igor Makanu:

pourquoi des écrans noirs "Update" apparaissent-ils lors du changement de TF ?

j'ai ouvert le graphique que j'utilisais avant (H1 sur EURUSD), j'ai laissé l'indicateur, je n'ai rien fait pendant 2-3 minutes, puis je suis passé à un graphique plus bas (M30...M1), peut apparaître pendant 10 secondes "écran noir de mise à jour".

et cet écran noir dépend de la construction - quand le terminal est sans écran noir, et quand cela m'ennuie vraiment, parce que vous savez exactement quel historique est chargé, vous avez juste besoin de rendre un graphique au terminal, et pourquoi attendre pour cet écran noir


Par exemple, si l'indicateur fonctionne sur M5 et que toutes les 30 minutes, il est appelé sur H1, est-ce que CopyBuffer() obtiendra toujours les données correctes de H1 ?

ou pas un fait, donc "tirer l'indicateur" sur H1 à chaque tick(nous ne considérons pas encore les variantes de rupture de connexion).

Je pense, d'après les propos de Slava, que ce n'est pas un fait.

Comme tous les calculs ne sont effectués que sur le tick, la chaîne d'indicateurs liés peut ne pas être terminée et nous devrons attendre le prochain tick.

Mais il y a quelques problèmes intéressants, dont je n'ai pas trouvé les réponses dans la documentation.

Que faire quand il n'y a pas de ticks (par exemple, pendant le week-end) ? Si vous placez un indicateur qui fonctionne dans le cadre temporel actuel, il sera dessiné sans problèmes, et ce qui est intéressant, c'est qu'il n'a pas besoin d'un tick pour être reçu ! Mais si l'indicateur demande des données d'un autre cadre temporel, il ne fera rien jusqu'à ce qu'un nouveau tick arrive, et il n'y a pas de tick qui arrive - le week-end !

Si nous appelons ChartRedraw (ChartID ()) dans le timer, alors pour certain Comment (cnt) ; oùcnt est incrémenté de 1, nous voyons que cnt fonctionne correctement à l'écran, mais l'indicateur n'est pas dessiné.

Lorsque je rafraîchis l'écran avec le bouton Rafraîchir du menu contextuel, l'indicateur est redessiné du début à la fin.

Mais dès que vous rafraîchissez l'écran avec lebouton Refresh, l'indicateur est dessiné sans problème.


HH Votre exemple du second indicateur fonctionne, mais le code de l'Expert est plus rapide.

 
Andrey Dik:

que faire lorsqu'il n'y a pas de ticks (week-end par exemple) ? si vous mettez un indicateur travaillant sur le TF courant, il sera dessiné sans problèmes, et ce qui est intéressant - l'arrivée d'un tick n'est pas nécessaire pour cela !

ce n'est pas nécessaire

lorsque vous dessinez l'indicateur sur le graphique, il y a une séquence d'appels strictement définie : OnInit() et immédiatement OnCalculated(). c'est-à-dire que le premier OnCalculated() est appelé avant la réception du tick, c'est pourquoi prev_calc doit être comparé à 0. à la réception du tick ou à la connexion avec le serveur, OnCalculated() sera appelé à nouveau etprev_calc sera égal à zéro.

Andrey Dik:

Il s'avère que ChartRedraw () et Update by button ne sont pas la même chose, même si je peux penser le contraire.

Vous devriez probablement utiliser ChartSetSymbolPeriod() avec les paramètres NULL et la période actuelle, cela devrait vous aider.

 
Igor Makanu:

Vous devriez probablement utiliser ChartSetSymbolPeriod() avec les paramètres NULL et la période actuelle, ce qui devrait vous aider.

ChartSetSymbolPeriod

L'appel ChartSetSymbolPeriod avec le même symbole et la même période peut être utilisé pour rafraîchir le graphique (similaire à la commande Refresh dans le terminal). L'actualisation du graphique, à son tour, déclenche le recalcul des indicateurs qui lui sont attachés. Ainsi, vous pouvez recalculer l'indicateur sur le graphique même lorsqu'il n'y a pas de ticks (par exemple le week-end).

Ça a aidé. Et aussi, comme je m'en souviens maintenant, Ac Pushkin disait :

Oh, combien de découvertes merveilleuses
Préparentnotreesprit éclairé
Et l'expérience, le fils des dures erreurs,
Et le génie, l'ami des paradoxes,
Et le hasard, Dieu l'inventeur.

 
Andrey Dik:


Que faire lorsque les ticks n'arrivent pas (par exemple, le week-end) ? Si l'indicateur fonctionne dans le cadre temporel actuel, il sera dessiné sans problème, et ce qui est intéressant - il n'a pas besoin d'un tick pour venir ! Mais si l'indicateur demande des données d'un autre cadre temporel, il ne peut rien faire jusqu'à ce qu'un nouveau tick arrive, et il n'arrive pas - le week-end !


Dans l'autre période, on obtiendra les données qui sont prêtes à l'heure actuelle. Ainsi, à la sortie, toutes les données seront parfaitement synchronisées.

 
Slava:

J'ai une question sur le timing. Devons-nous nous attendre à ce qu'il n'y ait pas de clonage de la base de données des devis pour chaque agent local pendant l'optimisation dans les prochaines versions ?

En ce moment, il prend une TRES grande quantité de mémoire à cause de cela. Il faut soit désactiver les agents.

Raison: