G001: Est-il possible de mettre en boucle une demande comme celle-ci pour ouvrir une commande ? )
Pas souhaitable. Imaginez, par exemple, qu'au lieu de TRADE_RETCODE_DONE, le serveur renvoie la réponse que la commande a été passée. Votre code surchargerait alors le serveur avec le même type de demandes.
Yedelkin: Pas souhaitable. Imaginez, par exemple, qu'au lieu de TRADE_RETCODE_DONE, le serveur renvoie une réponse indiquant qu'une commande a été passée. Ensuite, votre code inondera le serveur avec le même type de demandes.
Peu probable. Regardez la description de la fonction OrderSend(). Elle devrait vous dire que si elle est exécutée avec succès, vous devez encore vérifier le code de retour. Nous allons donc devoir utiliser la méthode la plus fastidieuse : prendre une liste de codes de retour et réfléchir au comportement du programme pour chacun de ces codes. C'est-à-dire "nous avons envoyé OrderSend(), obtenu le code de retour, réagi au retcode que nous avons reçu".
Le deuxième point. Il est préférable d'utiliser le modèle d'événement. C'est-à-dire ne pas boucler l'exécution de la fonction après l'arrivée d'un tick, et après plusieurs tentatives infructueuses, quitter la fonction et attendre un nouveau tick.
Si vous n'avez pas de compte, veuillez vous inscrire
Autorisez l'utilisation de cookies pour vous connecter au site Web MQL5.com.
Veuillez activer les paramètres nécessaires dans votre navigateur, sinon vous ne pourrez pas vous connecter.
Vous êtes connecté. L'authentification à deux facteurs a été désactivée. Configurez-la à nouveau et scannez un nouveau code QR, ou continuez avec l'authentification à deux facteurs désactivée.
Comment puis-je déterminer quand la prochaine barre s'ouvrira, c'est-à-dire celle qui ne s'est pas encore formée ?
Est-il possible de mettre en boucle une demande comme celle-ci pour ouvrir une commande ? )
Pas souhaitable. Imaginez, par exemple, qu'au lieu de TRADE_RETCODE_DONE, le serveur renvoie une réponse indiquant qu'une commande a été passée. Ensuite, votre code inondera le serveur avec le même type de demandes.
Est-ce que ce serait mieux ?
Peu probable. Regardez la description de la fonction OrderSend(). Elle devrait vous dire que si elle est exécutée avec succès, vous devez encore vérifier le code de retour. Nous allons donc devoir utiliser la méthode la plus fastidieuse : prendre une liste de codes de retour et réfléchir au comportement du programme pour chacun de ces codes. C'est-à-dire "nous avons envoyé OrderSend(), obtenu le code de retour, réagi au retcode que nous avons reçu".
Le deuxième point. Il est préférable d'utiliser le modèle d'événement. C'est-à-dire ne pas boucler l'exécution de la fonction après l'arrivée d'un tick, et après plusieurs tentatives infructueuses, quitter la fonction et attendre un nouveau tick.
Il faudra bien que vous le fassiez un jour de toute façon :) Je parle de ma propre expérience.
Désolé, comment faire pour qu'il n'y ait pas de condition dans le testeur, mais qu'il y ait une condition dans le testeur en mode visuel ?
La liste des propriétés ne le permet pas, et pour une raison quelconque, cette condition ne fonctionne pas pour moi :
if(MQL5InfoInteger(MQL5_TESTER)!=1 || MQL5InfoInteger(MQL5_TESTER)==1 && MQL5InfoInteger(MQL5_VISUAL_MODE)==1)
de cette condition ressort qu'elle sera performante dans trois situations :
1) Lorsque le testeur fonctionne
2)Lorsque le testeur ne fonctionne PAS
3) Quand le testeur visuel fonctionne
pour que la fonction fonctionne toujours, vous devriez probablement supprimer la deuxième condition et relier la première et la troisième avec &&.