[ARCHIVE] Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Nulle part sans toi - 3. - page 589

[DOCTORGAD]

ilunga:
Parce que ce sont des variables locales qui, dès le deuxième tic, stockent des déchets au lieu de billets.

Merci beaucoup ! Honnêtement, j'y ai pensé tout le temps !

[kellin]

Roman.:

Voir la bande-annonce. Placez son contenu dans le dossier Experts du terminal. Sélectionnez la période de l'instrument qui vous intéresse et placez-la sur le graphique du conseiller expert,

Définir les paramètres d'ouverture d'un ordre dans les variables externes de MetaTrader :

Ensuite, vous attendez la formation d'une nouvelle barre sur le cadre temporel sélectionné de l'instrument.

Lorsque le conseiller expert ouvre un ordre du marché, comparez l'heure de son ouverture avec l'heure d'ouverture d'une nouvelle barre.

Roman, comme promis, je veux vous montrer ce qui se passe en pratique lorsque l'on travaille avec l'Expert Advisor sur le "open at the opening". Tout d'abord, l'EA est déclenché sur le prochain tick après avoir été placé sur le graphique en 1 heure et ouvre une deuxième transaction à l'ouverture de la bougie suivante. Pourquoi, je ne peux pas encore comprendre. Deuxièmement, le prix d'ouverture de la transaction ne coïncide pas avec le prix d'ouverture d'une nouvelle bougie :

24.02.2012,12:00,1.3392,1.3405,1.3383,1.3387,768 - la bougie s'ouvre à 1.3392 et l'ordre est déclenché à 1.3390. Je spécifie un slippage de 1 point dans les paramètres. Si j'entrais 0 pips, l'EA ne se déclencherait pas du tout.

J'ai joint le journal. L'important pour moi reste que l'ordre d'ouverture coïncide avec le prix d'ouverture du chandelier.

[Les]

Bonjour, messieurs. J'apprécierais une clarification.

Ai-je raison de comprendre que si dans le code les commandes OrderDelete et OrderSend sont écrites séquentiellement et si l'EA reçoit un signal pour exécuter les deux commandes (retrait + mise en place) sur le tick #1, alors:

- ces deux commandes ne peuvent pas être exécutées sur le même tick #1, et leur exécution est décalée d'au moins 3 ticks, et

- au tick #1, la commande OrderDelete est émise ;

- après que la commande OrderDelete a été soumise, le résultat n' est renvoyé qu' au prochain tick #2, et ce n'est que maintenant, au même tick #2, que la commande OrderSend peut être soumise ;

- le résultat de la commande OrderSend ne sera connu qu'au tick #3.

Est-ce le cas ?

Et est-il vrai qu'il n'est pas possible d'envoyer deux commandes à MT sur le même tick ?

J'écris un EA dans MT4.

Merci.

[ilunga]

Les:

Bonjour, messieurs. J'apprécierais une clarification.

Ai-je raison de comprendre que si dans le code les commandes OrderDelete et OrderSend sont écrites séquentiellement et si l'EA reçoit un signal pour exécuter les deux commandes (retrait + mise en place) sur le tick #1, alors:

- ces deux commandes ne peuvent pas être exécutées sur le même tick #1, et leur exécution est décalée d'au moins 3 ticks, et

- au tick #1, la commande OrderDelete est émise ;

- après que la commande OrderDelete a été soumise, le résultat n' est renvoyé qu' au prochain tick #2, et ce n'est que maintenant, au même tick #2, que la commande OrderSend peut être soumise ;

- le résultat de la commande OrderSend ne sera connu qu'au tick #3.

Est-ce le cas ?

Et est-il vrai qu'il n'est pas possible d'envoyer deux commandes à MT sur le même tick ?

J'écris un EA dans MT4.

Merci.

Une coche est une nouvelle citation. Et il n'y a pas de connexion entre les commandes OrderDelete et OrderSend.

S'il y a des mises à jour et des dérapages, le temps qu'un simple envoi d'ordre soit exécuté, une douzaine de ticks se seront écoulés. Et si le marché se trouve dans un appartement de nuit, les deux commandes peuvent être exécutées dans un tick.

[Alexey Subbotin]

Les:

Tout dépend de la vitesse des tics. En général, les fonctions qui renvoient une valeur, OrderDelete, OrderSend, etc. ne sont pas exécutées de manière asynchrone, c'est-à-dire que tant que l'opération complète n'est pas passée et qu'un code d'erreur n'est pas émis (ou NO_ERROR en cas de succès), l'opérateur suivant ne sera pas exécuté. Par ailleurs, plusieurs ticks peuvent s'exécuter pendant ce temps, mais ils ne seront pas traités par la fonction start().

Il peut également y avoir une collision lorsque, par exemple, un ordre déclenche un stoploss et que vous essayez d'ouvrir/de fermer un autre ordre sur le même tick. Dans ce cas, le serveur peut, dans certains cas, ne pas vous permettre d'exécuter l'opération.

C'est-à-dire que la réponse à vos questions est non, ce n'est pas le cas))

[Les]

ilunga:

Une coche est une nouvelle citation. Et il n'y a aucun lien avec le temps d'exécution des commandes OrderDelete et OrderSend.

S'il y a des mises à jour et des dérapages, le temps qu'un simple envoi d'ordre soit exécuté, une douzaine de ticks se sont écoulés. Et si le marché se trouve dans un appartement de nuit, alors les deux commandes peuvent être exécutées en un seul tick.

D'après ce que j'ai compris, MT tire des informations du serveur par le biais de ticks (et le serveur, à son tour, donne des réponses aux commandes simultanément à l'envoi de nouveaux ticks, ce qui optimise les coûts en fonction du temps). Et avant l'arrivée d'une nouvelle tique, on ne sait rien. C'est ce que je voulais dire. Mais peut-être que je me trompe dans cette hypothèse ? La question porte davantage sur la deuxième option que vous avez mentionnée, lorsque le tic-tac est lent, plutôt que sur une douzaine de tics.

Ai-je bien compris, donc, que l'obtention d'une réponse à la commande #1 n'est pas une condition préalable pour passer à la commande #2 et la traiter complètement ?

La réponse à la commande est la partie "non essentielle" de la commande ? Sa présence n'est-elle pas indispensable pour passer à la commande suivante ?

Nous avons eu une discussion avec alsu ci-dessous, et je pense que j'ai supposé la même chose que lui : qu'avoir une réponse est essentiel. Vous écrivez bien que deux commandes peuvent être exécutées sur un seul tick. L'information provenant du serveur arrive donc sans aucune connexion avec le flux de cotation ?

Merci.

[Les]

alsu:
Tout dépend de la vitesse des tics. En général, les fonctions qui renvoient une valeur, OrderDelete, OrderSend etc. ne sont pas exécutées de manière asynchrone, c'est-à-dire que tant que l'opération complète n'est pas passée et qu'un code d'erreur n'est pas renvoyé (ou NO_ERROR en cas de succès), l'opérateur suivant ne sera pas exécuté. Par ailleurs, plusieurs ticks peuvent s'exécuter pendant ce temps, mais ils ne seront pas traités par la fonction start().

Il peut également y avoir une collision lorsque, par exemple, un ordre déclenche un stoploss et que vous essayez d'ouvrir/de fermer un autre ordre sur le même tick. Dans ce cas, le serveur peut, dans certains cas, ne pas vous permettre d'exécuter l'opération.

C'est-à-dire que la réponse à vos questions est non, ce n'est pas le cas))

Comment est-ce que ce n'est pas le cas, si cela s'avère être exactement "le cas", selon vos propres mots ? )) Ou est-ce que je comprends encore mal quelque chose ? En réponse, vous écrivez que les fonctions sont exécutées de manière à ce que l'opérateur suivant ne soit exécuté qu'après le traitement du code d'erreur de l'opérateur précédent. Je pense que c'est ce que je voulais dire : que "deux commandes ne peuvent pas être exécutées sur le même tick #1", parce que la réponse - cette réponse ou le code d'erreur - apparaît plus tôt avec le nouveau tick. Ou pas ? Ou bien les réponses aux commandes sont-elles transmises dans un flux temporel distinct, sans rapport avec le flux des citations ? Mon erreur a peut-être été de supposer que les résultats de l'exécution des commandes sont renvoyés avec une nouvelle citation ?

Bien sûr, je faisais surtout référence à la situation où les tics sont lents.

[Юсуфходжа]

Veuillez me dire s'il est possible que le Conseiller Expert ne clôture que les transactions positives, malgré le signal de l'indicateur de clôturer la transaction et de les clôturer aux prochains signaux de l'indicateur, car elles sont rentables ?

[ilunga]

Les:

MT, d'après ce que j'ai compris, tire des informations du serveur potikovo (et le serveur, à son tour, donne des réponses aux commandes en même temps qu'il envoie de nouveaux ticks, ce qui optimise les coûts en temps). Et avant l'arrivée d'une nouvelle tique, on ne sait rien. C'est ce que je voulais dire. Mais peut-être que je me trompe dans cette hypothèse ? La question porte davantage sur la deuxième option que vous avez mentionnée, lorsque le tic-tac est lent, plutôt que sur une douzaine de tics.

Ai-je bien compris, donc, que l'obtention d'une réponse à la commande #1 n'est pas une condition préalable pour passer à la commande #2 et la traiter complètement ?

La réponse à la commande est la partie "non essentielle" de la commande ? Sa présence n'est-elle pas indispensable pour passer à la commande suivante ?

Nous avons eu une discussion avec alsu ci-dessous, et je pense que j'ai supposé la même chose que lui : qu'avoir une réponse est essentiel. Vous écrivez bien que deux commandes peuvent être exécutées sur un seul tick. L'information provenant du serveur arrive donc sans aucune connexion avec le flux de cotation ?

Merci.

Les réponses aux commandes et les tics sont distincts et sans rapport. S'il y a un dead flat, vous pouvez "attraper" plusieurs ordres ouverts/fermés sur le même tick.

[[Supprimé]]

Bonjour. Je ne suis pas du tout doué pour la programmation. Je ne suis pas très expérimenté en codage, alors s'il vous plaît aidez-moi à ajouter des positions de fermeture parStopLoss et TrailingStop à mon code. Le conseiller expert n'est pas le mien, mais la stratégie n'est pas mauvaise, donc les essais et les erreurs de retravailler l'EA pour moi - et pour être honnête, je suis déjà en train de souffler, et il n'y a pas beaucoup de temps - travail. Je l'ai déjà essayé et testé et, franchement, je n'ai pas le temps pour cela - le travail. Et voici ce que j'en fais :

//+------------------------------------------------------------------+
//|                                             stohastic_system.mq4 |
//|                                                    Анатолий      |                                                                  |
//+------------------------------------------------------------------+

extern double Lots=0.4;
extern int TakeProfit=50;
extern int NWave=2;
extern int K=9;
extern int D=3;
extern int slowing=5;
extern int Average_method=2;
extern int price_field=0;

int K_level=0;
int down=0;
int up=0;


int init()
  {

   return(0);
  }

int deinit()
  {

   return(0);
  }

int start()
  {
    int ticket=0;
    double stoch_1=iStochastic(NULL,0,K,D,slowing,Average_method,price_field,MODE_MAIN,1);
    double stoch_2=iStochastic(NULL,0,K,D,slowing,Average_method,price_field,MODE_MAIN,2);
    double stoch_3=iStochastic(NULL,0,K,D,slowing,Average_method,price_field,MODE_MAIN,3);
    int Hour_curr=TimeHour(TimeCurrent());
    
    if ((stoch_1>90)&&(stoch_2>70)) K_level=90;
    if ((stoch_1<10)&&(stoch_2<30)) K_level=10;  
    if(OrdersTotal()<1)
      {        
        if((Hour_curr>=1)&&(Hour_curr<24))//проверка сигналов только в этот промежуток времени
          {
            if((K_level==10)&&(stoch_1>10))//сигнал на покупку
              {
                RefreshRates();
                Print("Сигнал на покупку. stoch_1=",stoch_1," stoch_2=",stoch_2);
                ticket=OrderSend(Symbol(),OP_BUY,Lots,Ask,10,0,Ask+TakeProfit*Point,"buy_order1",1,0,Blue);
                
                K_level=10; 
                down=0;               
              }
            if((K_level==90)&&(stoch_1<90))//сигнал на продажу
              {
                RefreshRates();
                Print("Сигнал на продажу. stoch_1=",stoch_1," stoch_2=",stoch_2);
                ticket=OrderSend(Symbol(),OP_SELL,Lots,Bid,10,0,Ask-TakeProfit*Point,"sell_order1",1,0,Red);
               
                K_level=90;
                up=0; 
              }
          }
      }
    
   
   
    return(0);
  }