Erreurs, bugs, questions - page 2436
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
Pourquoi ?
Je ne perds rien.
Le fichier mqd est parfaitement formé (sans aucune perte), même par un tel conseiller expert.
Après cela, je l'ai lu d'une traite avec le tabla ajouté.
Les trames manquent même dans les calculs mathématiques rapides si vous ne les lisez pas après l'optimisation.
Le réseau n'est pas parfaitLes images disparaissent même lors de calculs mathématiques rapides si vous ne finissez pas de les lire une fois l'optimisation terminée.
Le réseau n'est pas parfaitApparemment, mes idées sur les cadres sont fausses, puisque vous semblez dire n'importe quoi.
Les trames n'ont pas besoin d'être lues pour être écrites. Dites-moi alors comment cela fonctionne réellement. Je n'ai pas travaillé avec des cadres par le biais du Cloud.
De la façon dont je le vois, un cadre n'est disponible que si vous l'ajoutez à un fichier mqd.
Apparemment, mes idées sur les cadres sont fausses, puisque vous semblez dire n'importe quoi.
Vous n'avez pas besoin de lire les cadres pour les écrire. Dites-moi alors comment cela fonctionne réellement. Je n'ai pas travaillé avec des cadres par le biais du Cloud.
De la façon dont je le vois, un cadre n'est disponible que s'il est ajouté au fichier mqd.
C'est exact. Le cadre est disponible à condition qu'il soit ajouté au fichier mqd. C'est à partir de là qu'il est lu par les fonctions du cadre.
C'est exact. Un cadre est disponible tant qu'il est ajouté au fichier mqd. C'est à partir de là qu'il est lu par les fonctions du cadre.
Ensuite, si je comprends bien, ceux qui affirment qu'il y a une perte de trames devraient vérifier leur présence dans OnTesterDeinit.
Je n'ai pas eu ce problème. La bibliothèque a été écrite pour l'accès aux cadres dans le mode normal de l'Expert Advisor dans le Terminal.
Je n'ai pas compris à quoi servent les 16 derniers octets.
Vous devez toujours terminer la lecture des cadres dans OnTesterDeinit. C'est comme notre patrie.
Ensuite, les gens se plaignent des cadres manquants.
C'est la première fois que j'entends parler de cette "Prière du Père". Où est-ce que ça dit ça ? OnTesterDeinit ne devrait-il pas être appelé après la réception de toutes les trames dans le terminal ? Si c'est le cas, cela devrait être mentionné dans la documentation, car il s'agit d'un comportement atypique.
Si vous voulez parler d'un arrêt forcé des tests par un utilisateur, alors il n'y a aucun sens à parler de disparition des cadres.
C'est la première fois que j'entends parler de ce "Notre Père". Où est-ce que ça dit ça ? OnTesterDeinit ne devrait-il pas être appelé après avoir reçu toutes les trames sur le terminal ? Si c'est le cas, cela devrait être mentionné dans la documentation, car c'est un comportement atypique.
Si vous voulez parler d'un arrêt forcé des tests par un utilisateur, il n'y a aucun sens à parler de disparition des cadres.
OnTesterPass peut facilement être appelé à la fin d'une passe, mais à ce moment-là, les données de la trame peuvent ne pas atteindre la passe en raison de l'imperfection du réseau.
Lorsque les gens disent que des images sont perdues, ils veulent souvent dire que OnTesterPass ne peut pas tout attraper.
Vous pouvez toujours tout obtenir à OnTesterDeinit, car l'Optimizer du côté du terminal arrête son travail non pas lorsque les agents ont tout compté, mais lorsqu'il attend que toutes les images arrivent.
OnTesterPass peut facilement être appelé à la fin d'un passage, mais les données de la trame du passage peuvent ne pas l'atteindre à ce moment-là en raison de la non-idéalité du réseau.
Donc, OnTesterPass est appelé sans qu'il y ait de trames ? Eh bien, c'est une erreur évidente. Cet événement signifie la réception d'une trame, pas la fin d'une passe.
Toutes les trames doivent arriver à OnTesterPass avant l'appel de l'événement OnTesterDeinit. C'est une logique saine et normale. Sauf si, encore une fois, nous parlons d'une interruption forcée du test.
Donc, OnTesterPass est appelé sans qu'il y ait de trames ? Eh bien, c'est une erreur évidente. Cet événement signifie la réception d'une trame, pas la fin d'une passe.
Toutes les trames doivent arriver à OnTesterPass avant l'appel de l'événement OnTesterDeinit. C'est une logique saine et normale. Sauf si, encore une fois, nous parlons d'une interruption forcée du test.
Apparemment, je me suis trompé. Je pensais que l'événement TesterPass était l'arrivée des données de réussite.
Donc OnTesterPass est appelé sans qu'il y ait de trames ? Alors c'est une erreur évidente. Cet événement signifie la réception d'une trame, pas la fin d'une passe.
Toutes les trames doivent arriver à OnTesterPass avant l'appel de l'événement OnTesterDeinit. C'est une logique saine et normale. Sauf si, encore une fois, nous parlons d'une interruption forcée du test.
OnTesterPass est appelé lorsqu'au moins un cadre est arrivé. Il peut se présenter sous la forme d'un paquet de cadres. Par conséquent, OnTesterPass doit accepter les images dans une boucle, et non une image à la fois. Mais si "après la dernière fois - jamais", OnTesterPass n'est pas appelé.
L'optimisation s'arrête lorsque le dernier résultat est arrivé. Les trames peuvent arriver plus tard, notamment si une grande quantité de données est transmise dans une trame, ou si plusieurs trames sont transmises en une seule fois. Par conséquent, nous devons organiser la réception des images restantes dans OnTesterDeinit, qui est lancé après la fin de l'optimisation - également dans la boucle.
C'est une logique normale et saine.
J'ai donné à plusieurs reprises des exemples de réception de trames exactement dans OnTesterDeinit, pas seulement dans OnTesterPass. Et c'est la réception de cadres complexes de différents types