Comment vérifier si une commande est sélectionnée - page 19
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
En principe oui, mais le "pointeur" devra avoir son propre pointeur. réfléchissez à ma proposition avec la fonction, elle me semble une solution universelle. bien sûr il y a une question sur la rapidité d'un tel code, mais cela semble être la troisième question.
Merci, je suis toujours heureux d'avoir une conversation constructive.
Ainsi, si la fonction A du programme sélectionne un certain ordre dans la boucle et appelle ensuite la fonction auxiliaire B de la bibliothèque, même si B sélectionne un autre ordre au cours du processus, la sélection de l'ordre dans la fonction A ne devrait pas être affectée par le retour.
Merci, je suis toujours heureux d'avoir une conversation constructive.
De rien, mais ne tirez pas de conclusions hâtives.
Si vous stockez la valeur de la fonction dans une variable, oui. Sinon, la fonction est globale et peut changer lors du premier appel.
Je suis un peu confus. Je voulais parler de la situation suivante : nous appelons la fonction de bibliothèque B() à partir de la fonction A() dans le module du programme principal, qui, par exemple, sélectionne simplement le premier ordre dans la liste (en supposant qu'il existe un ordre a priori) :
void B(){
OrderSelect(0,SELECT_BY_POS) ;
}
Lorsque le contrôle revient de la bibliothèque au module principal après l'appel de cette fonction, si nous appelons OrderTicket() ou toute autre fonction de ce module qui s'attend à ce que la commande soit présélectionnée, nous obtiendrons exactement la même erreur 4105. Mais si, avant l'appel de la fonction B dans le module principal, une autre commande a déjà été sélectionnée, elle le restera indépendamment du nouveau Select dans la bibliothèque, car la commande actuellement sélectionnée, si je comprends bien, n'est unique qu'à l'intérieur du module.
Mais si nous appelons la même fonction B à partir de la fonction A du module principal, l'ordre sélectionné dans la fonction A avant l'appel à B deviendra l'ordre 0 (c'est-à-dire que l'ordre actuellement sélectionné après le retour de la fonction B sera l'ordre 0, quel que soit l'ordre sélectionné avant l'appel à B).
Par conséquent, si nous appelons une fonction qui utilise OrderSelect par elle-même, nous devons nous assurer que lorsque nous revenons de cette fonction, l'ordre que nous avons choisi avant d'appeler cette fonction, afin de pouvoir l'utiliser plus tard. Si vous ne vous en assurez pas, cela peut conduire à des erreurs logiques difficiles à trouver dans votre code.
Plus précisément, le "pointeur" - l'état de la sélection de la commande en cours - est global au sein du module, c'est-à-dire que ce pointeur est le même pour la bibliothèque et différent pour le module de programme. Cela signifie que si la fonction A du programme sélectionne un certain ordre dans la boucle et appelle ensuite la fonction auxiliaire B de la bibliothèque, même si, pendant son fonctionnement, B sélectionne un autre ordre, la sélection de l'ordre dans la fonction A ne doit pas être modifiée au retour. Mais si les deux fonctions sont à l'intérieur d'un module, alors au retour de la fonction B, nous devons nous souvenir et restaurer la sélection de l'ordre actuel avant et après l'appel de B dans la fonction A elle-même ou dans la fonction B lorsqu'elle commence et termine son travail, afin que la logique du travail de la fonction A ne soit pas violée à ce moment-là.
Votre point de vue est clair...
Je vois une analogie avec les constructions populaires d'Expert Advisor quand les numéros de tickets sont stockés dans des variables et utilisés plus tard (sur les prochains ticks, comme si un byticket a été ouvert, etc...)...
Si vous voulez obtenir un ticket de la dernière commande ouverte, utilisez simplement les propriétés de cette commande, OrderSelect() et tout ira bien.Cela signifie qu'à tout moment, le conseiller expert doit "comprendre" dans quel état se trouve la stratégie commerciale et agir en fonction de cet état, indépendamment de ce qui se passe avec l'électricité et les autres conseillers experts en activité dans le terminal.
Lorsque le contrôle revient de la bibliothèque au module principal après l'appel de cette fonction, si nous appelons la fonction OrderTicket() ou toute autre fonction de celle-ci conçue pour que la commande soit présélectionnée, nous obtiendrons exactement la même erreur 4105. Mais si, avant d'appeler la fonction B dans le module principal, une autre commande a déjà été sélectionnée, elle le restera indépendamment du nouveau Select dans la bibliothèque, car la commande actuellement sélectionnée, si je comprends bien, n'est unique qu'à l'intérieur du module.
il a été prouvé que cela fonctionne de cette façon, ou pensez-vous que cela fonctionne de cette façon ?
Pour moi, il n'y a pas de séparation entre les modules et les bibliothèques... une fois compilé, le code fonctionne comme une seule construction...
chaque fois que OrderSelect() est appelé, le même OrderTicket() de la dernière commande sélectionnée sera retourné...
Je pense que ça devrait fonctionner comme ça...
il est prouvé que ça marche comme ça, ou pensez-vous que ça marche ?
Pour moi, il n'y a pas de division en modules et bibliothèques... après la compilation, le code fonctionne comme une seule construction...
Partout où OrderSelect() est appelé, le même OrderTicket() de la dernière commande sélectionnée sera retourné...
Je pense que ça devrait fonctionner comme ça...
Il a été vérifié que l'ordre sélectionné dans la bibliothèque n'est pas l'ordre sélectionné lorsqu'il est renvoyé dans le module principal. Par conséquent, l'ordre qui est logiquement sélectionné devrait être le dernier ordre sélectionné dans le module principal, bien que je ne l'aie pas encore vérifié.
J'ai résolu ce problème pour moi-même en créant des wrappers pour les fonctions de la bibliothèque dans le fichier de la bibliothèque d'inclusion mqh similaire à celui qui suit :
bool GetOrder(int a=0){
return(OrderSelect(_GetOrder(a),SELECT_BY_TICKET)) ;
}
À propos, vous ne pouvez pas non plus passer de paramètres par défaut aux fonctions de la bibliothèque.
Ici, _GetOrder(int a) est la fonction de la bibliothèque elle-même qui trouve et renvoie un ordre. La fonction est appelée à partir de la bibliothèque avec un paramètre explicite "a", dans la fonction wrapper il est 0 par défaut, plus le ticket retourné dans le wrapper est sélectionné à nouveau dans le module du programme principal, parce que sa sélection dans la fonction bibliothèque n'atteindra pas le "destinataire".
Je le pense aussi, peu importe d'où cette fonction est appelée, elle donnera un ensemble de paramètres sélectionnés pour un ordre particulier et le logiciel ne les changera pas jusqu'à la prochaine fois que cette fonction sera appelée, peu importe d'où elle est appelée.
Sinon, pourquoi envelopper cette fonction dans une fonction supplémentaire, totalement inutile ?
PYSYS. Conseil - créez une variable entière statique, passez la valeur de l'ordre après l'ouverture, elle ne changera pas, jusqu'à ce que vous le vouliez, et réalisera exactement ce que vous avez prévu.
Vérifié que l'ordre sélectionné dans la bibliothèque n'est pas l'ordre sélectionné lors du retour au module principal. En toute logique, l'ordre sélectionné au retour devrait donc être le dernier ordre sélectionné dans le module principal, bien que je ne l'aie pas encore vérifié.
Cette déclaration doit être clarifiée : La déclaration est vraie si nous parlons d'un module (bibliothèque) qui est compilé SEULEMENT (*.mg4-libraries du dossier des bibliothèques). Pour les modules qui font partie du fichier principal compilé (*.mgh-library), cette affirmation n'est PAS vraie !
MQH n'est pas un module séparé, mais un insert dans le module principal, situé dans un fichier différent. Il s'agit donc bien sûr d'une bibliothèque .ex4 distincte.