Comment vérifier si une commande est sélectionnée - page 4
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 fait, il y a eu beaucoup de démagogie.
Tout ce dont nous avons besoin pour savoir si une commande est sélectionnée ou non.
Je l'ai expliqué au début du sujet, n'est-ce pas clair ?
Nous avons une fonction qui traite potentiellement les ordres, c'est-à-dire qu'elle les sélectionne et les analyse. Il peut être appelé à partir de différents fragments de code, y compris ceux qui ont déjà un ordre sélectionné avec lequel travailler. Si cette fonction distincte ne sauvegarde pas l'ordre déjà sélectionné et ne rétablit pas sa sélection, cela entraînera des erreurs dans la logique de l'EA, car lorsque nous reviendrons de cette fonction, l'ordre sélectionné avant son appel sera erroné. Ainsi, pour éviter ces erreurs, nous devons nous souvenir de l'ordre actuellement sélectionné à l'endroit de son appel dans chaque fonction auxiliaire qui traite les ordres par elle-même et retourner sa sélection lorsqu'elle a terminé. Comment accomplir cette tâche facilement et sans générer d'erreurs - c'est la question du thème actuel
// Cela implique qu'un ordre est sélectionné via OrderSelect (ou qu'il y a une erreur).
Pourquoi une erreur ? Si l'ordre n'est pas sélectionné, cette action n'est tout simplement pas nécessaire, mais il semble impossible de savoir à l'avance si l'ordre est sélectionné ou non sans astuces particulières.
// Alors pourquoi devrait-il être sélectionné à nouveau ?
C'est pourquoi, après le retour de cette fonction dans la partie appelante du code, l'ordre sélectionné dans cette partie du code avant l'appel de la fonction reste sélectionné - de sorte que les opérations effectuées avec l'ordre actuellement sélectionné n'entraînent pas d'erreurs.
Non, il est vraiment dans le réservoir.
J'ai tout expliqué au début du fil de discussion, est-ce si peu clair ?
Nous avons une fonction qui travaille potentiellement avec les ordres, c'est-à-dire qu'elle les sélectionne et les analyse. Il peut être appelé à partir de différents fragments de code, y compris ceux qui ont déjà un ordre sélectionné avec lequel travailler. Si cette fonction séparée ne sauvegarde pas l'ordre déjà sélectionné et ne rétablit pas sa sélection, cela entraînera des erreurs dans la logique de l'EA, puisque lorsque nous reviendrons de cette fonction, l'ordre sélectionné avant son appel sera erroné. Ainsi, pour éviter ces erreurs, nous devons nous souvenir de l'ordre actuellement sélectionné à l'endroit de son appel dans chaque fonction auxiliaire qui traite les ordres par elle-même et retourner sa sélection lorsqu'elle a terminé. Comment accomplir cette tâche facilement et sans générer d'erreurs, telle est la question de ce sujet.
1. Pour transmettre à la fonction le numéro de l'ordre sélectionné avant qu'elle ne soit appelée.
2. Lorsque la fonction se termine, sélectionnez à nouveau le même ordre.
Comment puis-je savoir ce que vous voulez obtenir ? Vous devrez être plus précis :(
1. Envoyer le numéro de l'ordre sélectionné avant l'appel de la fonction.
2. Lorsque la fonction se termine, sélectionnez à nouveau le même ordre.
Comment puis-je savoir ce que vous voulez obtenir ? Vous devriez être plus clair :(
Oui, je le comprends, cependant, j'aimerais écrire des fonctions informatives, telles que le profit total ou les ordres ouverts, qui peuvent être appelées sans penser qu'elles changeront quelque chose dans la logique d'exécution du programme. C'est logique, je pense.
Il n'est pas toujours trivial de passer l'ordre sélectionné dans la fonction appelante, imaginez que l'imbrication des appels >1, faut-il passer un ticket à chaque fonction pour qu'une fonction d'information mineure puisse l'utiliser ?
Il serait plus logique de donner un wrapper à OrderSelect et OrderTicket, qui stockerait et obtiendrait des informations sur la commande actuellement sélectionnée à partir d'une variable séparée, mais ici nous nous retrouvons avec une double information (le terminal sait déjà si la commande est choisie, mais nous ne pouvons pas passer cette information sans une erreur potentielle). En d'autres termes, soit nous obtenons une duplication d'informations ou une complication excessive des fonctions (nous passons également l'ordre sélectionné du tout début dans chaque paramètre), soit nous devons générer des erreurs d'exécution du programme.
Oui, je comprends, mais j'aimerais écrire des fonctions d'information, telles que le bénéfice total ou le nombre d'ordres ouverts, qui peuvent être appelées sans penser qu'elles vont modifier la logique d'exécution du programme. C'est logique, je pense.
C'est logique, mais dans ce cas, nous devrions au moins diviser les fonctions en "blanches" et "noires". Le numéro d'ordre sélectionné dans le premier cas est sauvegardé, et lorsqu'il est violé dans le second, il est restauré.
Cela semble être aussi simple que cela.
Oui, je comprends, mais j'aimerais écrire des fonctions d'information, telles que le bénéfice total ou le nombre d'ordres ouverts, qui peuvent être appelées sans penser qu'elles vont modifier la logique d'exécution du programme. C'est assez logique, je pense.
Il n'est pas toujours trivial de passer l'ordre sélectionné dans la fonction appelante ; imaginez que l'imbrication des appels >1, ne devrions-nous pas passer un ticket à chaque fonction pour qu'une fonction d'information mineure puisse l'utiliser ?
Regardez la bibliothèque de fonctions de Kim et vous verrez que chaque fonction énumère, sélectionne et vérifie le ticket, puis ce que vous devez savoir. Votre "logique" ne vous permet pas d'apprendre les règles de base de la programmation.
Vous avez un aîné dans un champ, et un oncle à Kiev.
Regardez la bibliothèque de fonctions de Kim et voyez que chaque fonction effectue l'énumération, la sélection et la vérification du ticket, puis ce qu'il faut apprendre. Votre "logique" ne vous permet pas d'apprendre les règles alphabétiques de la programmation.
Un petit aîné dans un jardin et un petit oncle à Kiev.
Boris, ce n'est pas nécessaire. Je parle de l'ABC.