Servicedesk. Plaintes, suggestions. - page 5

Nouveau commentaire
 
Alexey Kozitsyn:
C'est à peu près ça. Si je comprends bien, il s'agit d'indicateurs sur mql5 ? Selon vos propos, il s'avère que si un indicateur appelle un autre indicateur, alors il ne rendra pas hors ligne ? Ou bien, combien de niveaux devraient-ils y avoir pour répéter le problème décrit par vous ?

Je ne l'ai pas étudié en profondeur, maintenant je parle de logique:

- Avant de commencer à construire un indicateur dans OnCalculate, je vérifie si tous les indicateurs nécessaires à la construction correcte de cet indicateur ont été construits. Si ce n'est pas le cas, il faut sortir de la boucle, car on ne peut pas attendre dans la même exécution de OnCalculate (cela a été confirmé par Renate). Il s'ensuit que cet indicateur doit sortir de la boucle et attendre à nouveau la mise à jour, n'est-ce pas ? et s'il y a plusieurs niveaux d'imbrication, alors l'utilisateur doit appeler cette option depuis le menu graphique, c'est-à-dire si nous supposons que chaque fois que les indicateurs entre

- le fait que dans les indicateurs appelés par iCustom, OnTimer et OnChartEvent ne fonctionnent pas est également un fait confirmé par les modérateurs dans le fil suivant et je l'ai vérifié moi-même.

 
Ilya Malev:

Je ne l'ai pas étudié en profondeur, maintenant je parle logiquement :

- j'ai une vérification avant de commencer à construire un indicateur dans OnCalculate - si tous les indicateurs qui sont nécessaires pour la construction correcte de cet indicateur ont été construits. si non - sortir du cycle, parce que vous ne pouvez pas attendre dans la même session OnCalculate (que vous ne pouvez pas attendre - confirmé par Renat) cela signifie que cet indicateur doit sortir du cycle et attendre à nouveau pour la mise à jour, n'est-ce pas ? et s'il y a plusieurs niveaux d'imbrication de ce type, alors l'utilisateur devra appeler cette option à partir du menu graphique à chaque fois, il est supposé que chaque indicateur entre voisins

- le fait que dans les indicateurs appelés par iCustom, OnTimer et OnChartEvent ne fonctionnent pas est également un fait confirmé par les modérateurs dans le fil suivant et je l'ai vérifié moi-même.

Eh bien, comment avez-vous résolu le problème de ces dessins ?
 
Alexey Kozitsyn:
OK, comment avez-vous résolu le problème de ces constructions ?
J'avais un ensemble d'indicateurs complexes interdépendants dans MT4 qui devaient être transférés dans MT5. J'ai décidé de faire un système de classe pour inclure les indicateurs les uns dans les autres et les calculer à la fois sans iCustom et sans tampon d'indicateur.
 
Ilya Malev:
J'avais un ensemble d'indicateurs complexes interconnectés dans MT4, qui devaient être transférés dans MT5. J'ai décidé de faire un système de classe pour inclure les indicateurs les uns dans les autres et les calculer à la fois sans iCustom et sans tampon d'indicateur.
Radical. Avez-vous parlé de l'ajout d'un accès au minuteur pour les indicateurs imbriqués ?
 
Alexey Kozitsyn:
Radicalement. Et pourquoi ne pas ajouter l'accès à la minuterie aux indicateurs imbriqués ?

Je n'ai pas posé de questions sur ces plans, car il n'y avait aucune possibilité d'attendre de toute façon.

Dans ce cas, ils ajouteraient la possibilité d'attendre le type Sleep() dans les indicateurs, de sorte que l'on puisse attendre que les données soient créées sans sortir de OnCalculate, comme dans les scripts. D'ailleurs, cela concerne aussi les séries chronologiques - l'indicateur ne pourra pas charger les données nécessaires sans l'arrivée de nouveaux ticks.

 
Et ce problème, tel que je le comprends, ne peut même pas être résolu en s'intégrant l'un à l'autre - le week-end, si vous ne voulez pas cliquer sur Rafraîchir, vous devez d'abord charger l'historique pour toutes les paires/FT nécessaires avec le script, et seulement ensuite exécuter l'indicateur.
 
Ilya Malev:

Je n'ai pas posé de questions sur ces plans, car il n'y a pas de possibilité d'attendre de toute façon.

Dans ce cas, nous devrions ajouter la possibilité d'attendre le type Sleep() dans les indicateurs, afin que l'on puisse attendre que les données soient créées sans sortir de OnCalculate, comme dans les scripts. D'ailleurs, cela concerne aussi les séries temporelles - l'indicateur ne pourra pas charger les données nécessaires sans l'arrivée de nouveaux ticks.

Sleep() est inutile à demander - un seul fil pour tous les indicateurs. Il est peu probable que ce système soit remanié. Et si nous mettons en œuvre la minuterie, le besoin de la fiche disparaîtra.
 
Ilya Malev:
Et ce problème, tel que je le comprends, ne peut être résolu même en s'intégrant l'un à l'autre - en fin de semaine, si vous ne voulez pas cliquer sur Rafraîchir, vous devez d'abord charger l'historique pour toutes les paires/FT nécessaires avec le script, et seulement ensuite exécuter l'indicateur.
Je viens d'avoir une idée. Et si nous faisions ce qui suit. Comment informer l'indicateur principal des données que nous voulons recevoir, obtenir ces données à partir du chronomètre et ensuite calculer facilement tous les indicateurs joints ?
 
Alexey Kozitsyn:
Sleep() est inutile de demander - un thread pour tous les indicateurs. Et il est peu probable que ce système soit repensé. Et si nous mettons en œuvre le minuteur, il n'y aura pas besoin dans le slip.
Je ne dirais pas qu'il disparaît, mais iCustom et l'ensemble du système d'indicateurs seront utilisables sans tambourin.
 
Alexey Kozitsyn:
Une idée vient de me venir à l'esprit. Et si nous mettions en œuvre ce qui suit. Comment informer l'indicateur principal des données que nous voulons recevoir, recevoir ces données du chronomètre et ensuite calculer tous les indicateurs joints ?
Tous les indicateurs ont le même fil, avec ou sans minuterie. Ou je ne comprends pas votre idée.
123456789101112...28
Nouveau commentaire