Comment vérifier si une commande est sélectionnée - page 18

 
En fait, l'erreur se trouve dans le tout premier message, contrairement au topicstarter, j'ai écrit tous les mouvements, c'est-à-dire que je n'écris que sur ce qui a été testé.
 
keekkenen:
peu importe ce que vous pensez sur la façon d'écrire du code, l'essentiel est que le code fonctionne correctement, au lieu d'apporter votre code et de demander où vous vous trompez... encore une fois, il n'y a pas d'erreur 4105 si le billet est correct

Ce que vous dites est faux, car l'erreur 4105 se produit lors de l'appel de fonctions auxquelles il n'est pas nécessaire de passer un ticket.

Par exemple, lorsque OrderTicket() est appelé si OrderSelect() n'a pas été appelé avant OrderTicket() - c'est la situation discutée dans ce fil de discussion.

 

Non, ce que je voulais dire, c'était une sélection garantie de mon ordre pour chacune des fonctions, quelles que soient les transitions (sorties) vers l'extérieur.

c'est-à-dire en sauvegardant la dernière commande sélectionnée pour chaque fonction de votre

 
FAQ:

Non, ce que je voulais dire, c'était une sélection garantie de mon ordre pour chacune des fonctions, quelles que soient les transitions (sorties) vers l'extérieur.

c'est-à-dire en sauvegardant la dernière commande sélectionnée pour chaque fonction comme sa propre

Si plusieurs fonctions imbriquées contrôlent la dernière commande sélectionnée - c'est-à-dire qu'une fonction en appelle une autre et qu'une autre en appelle une troisième, alors chaque fonction conservera la sélection de la commande au moment où elle est appelée et ramènera la sélection à cet état au retour, si j'ai bien compris la question. Mais c'est une solution très délicate. En général, il est peu probable qu'il y ait plus d'un niveau d'imbrication. L'essentiel est de contrôler l'environnement de chacune de ces fonctions, afin qu'un appel de cette fonction ne provoque pas d'erreurs logiques dues à la réinitialisation d'une sélection d'ordre précédente. Ceci n'est nécessaire que pour les fonctions de service qui peuvent être appelées à partir de la boucle principale de récupération des commandes et qui récupèrent toujours les commandes elles-mêmes afin de calculer quoi que ce soit.

 

À propos, il semble que si la fonction de service se trouve dans la bibliothèque, il n'est pas nécessaire de sauvegarder le "pointeur"(sélection de la commande), n'est-ce pas ? Comme l'EA principal et la bibliothèque ont leur propre "pointeur", c'est-à-dire qu'un ordre sélectionné dans la bibliothèque ne sera pas sélectionné dans l'EA et vice versa.

Cela semble être une solution parfaite au problème si les fonctions A et B ne sont pas situées dans le même module.

 

Idéologie : avoir une fonction de sélection des commandes (une pour toutes) avec les filtres nécessaires à l'extérieur (de toute façon, dans chaque fonction, vous devez sélectionner cette commande quelque part (très probablement au début)).

int OrdersTicket(filters, int function_id, bool new = false){static int tickets[functions count];int ticket = -1;
   if(!new){
      if(OrderSelect(tickets[function_id],SELECT_BY_TICKET)){return(OrderTicket());}
   }
   // Выбор и возврат тикета ордера с нужными фильтрами
   return(ticket);
}

qui retournera sûrement le ticket de la commande précédemment choisie (dans cette fonction), ou bien faire une nouvelle recherche avec les filtres que nous avons spécifiés

Dans ce cas, la construction ticket = OrdersTicket() ; fonctionnera parfaitement.

 
Ant_TL:

Ce que vous dites est faux, car l'erreur 4105 se produit lors de l'appel de fonctions auxquelles il n'est pas nécessaire de passer le ticket.

Par exemple, lorsque OrderTicket() est appelé si OrderSelect() n'a pas été appelé avant OrderTicket() - c'est la situation discutée dans ce fil de discussion.


d'où vient le ticket des paramètres EA, fichier externe - d'où vient-il ?

si oui, alors oui, il y aura une erreur, car le fait de l'appel à OrderSelect() reste au départ sur les ticks suivants (au moins dans le testeur),...

 
Ant_TL:

À propos, il semble que si la fonction de service se trouve dans la bibliothèque, il n'est pas nécessaire de sauvegarder le "pointeur" (sélection de la commande), n'est-ce pas ? Comme l'EA principal et la bibliothèque ont leur propre "pointeur", c'est-à-dire qu'un ordre sélectionné dans la bibliothèque ne sera pas sélectionné dans l'EA et vice versa.

Cela semble être une solution parfaite au problème si les fonctions A et B ne sont pas situées dans le même module.


Tout dépend du degré de globalité de la variable externe.
 
Ant_TL:

À propos, il semble que si la fonction de service se trouve dans la bibliothèque, il n'est pas nécessaire de sauvegarder le "pointeur" (sélection de la commande), n'est-ce pas ? Comme l'EA principal et la bibliothèque ont leur propre "pointeur", c'est-à-dire qu'un ordre sélectionné dans la bibliothèque ne sera pas sélectionné dans l'EA et vice versa.

Cela semble être une solution parfaite au problème si les fonctions A et B ne sont pas situées dans le même module.


Je vais passer. Je ne peux pas vous aider avec autre chose. Tourne et tourne sans moi ! !!
 
FAQ:

Tout dépend du caractère global de la variable externe.

Plus précisément, le "pointeur" - l'état de lasé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 situées à l'intérieur d'un module, au retour de B, la sélection de l'ordre en cours doit être stockée et restaurée soit avant et après l'appel de B dans A lui-même, soit dans B au début et à la fin de son travail, afin que la logique du travail de A ne soit pas violée à ce moment-là.

Raison: