Auto-apprentissage du langage MQL5 à partir de zéro - page 28
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
C'est vrai ! Tout le monde essaie d'apprendre la programmation en utilisant des idées fausses sur les logiciels basées sur l'expérience de la vie. Par exemple, qu'un programme est comme un texte dans un livre avec une table des matières, une introduction, une table des matières et une conclusion. C'est-à-dire que le programme est une sorte de schéma séquentiel du début à la fin. Au début, cette idée fonctionne, mais ensuite, au fur et à mesure que le programme devient plus complexe, des difficultés apparaissent, et il n'est pas possible d'écrire un programme qui fonctionne de manière fiable. Kovalev est très doué pour rendre des services baissiers : il tente d'expliquer au lecteur, à l'aide de son appareil conceptuel accessible, que le programme est le même livre avec tel ou tel schéma. Mais il n'y a pas de combines ! Le script a un "schéma" fondamentalement différent de celui du conseiller expert, et le conseiller expert a un schéma différent de celui de l'indicateur.
Vasiliy Sokolov:
... 4) Le bloc le plus étrange est le bloc "traitement des erreurs". Vous pouvez y entrer, mais vous ne pouvez pas en sortir. C'est-à-dire que le programme a attrapé une erreur et reste dans ce bloc (il doit rester suspendu jusqu'à ce qu'il soit complètement redémarré, ou, mieux encore, le terminal reste suspendu en permanence, pour être sûr qu'il ne fera plus d'erreurs - c'est l'idée !) ...
Salut Vasiliy ! Merci pour cette explication détaillée et très compétente ! La seule chose avec laquelle je ne suis pas d'accord est le point 4. Le fait est que les flèches vont à la fois vers et depuis l '" unité de traitement des erreurs". La ligne qui relie cette unité à l'autre a des flèches à ses extrémités et, du programme d'informatique de l'institut, je me souviens encore qu'elle signifie un processus à double sens, c'est-à-dire un va-et-vient. Par conséquent, je n'ai aucun doute sur la situation. Quant au reste de votre message, tout est clair pour moi.
Salutations, Vladimir.
Bonjour Vasily ! Merci pour cette explication détaillée et hautement qualifiée ! La seule chose avec laquelle je ne suis pas d'accord est le point 4. Le fait est que les flèches vont à la fois vers et depuis "l'unité de traitement des erreurs". La ligne qui relie cette unité à l'autre a des flèches à ses extrémités et, du programme d'informatique de l'institut, je me souviens encore qu'elle signifie un processus à double sens, c'est-à-dire un va-et-vient. Par conséquent, je n'ai aucun doute sur la situation. Quant au reste de votre message, tout est clair pour moi.
Salutations, Vladimir.
C'est vrai, la première a été adoptée :-)
Utilisez son expa comme modèle dans vos recherches - code compétent !
là et
.
и
Inverser et d'autres trucs et brancher des bibliothèques standard dans le code au début pour simplifier la position d'ouverture fie - ETUDIER ET NE PAS SE SOUCIER.
L'indicateur"Positions : une seule" défini sur"true" permet au conseiller expert de ne pas avoir plus d'une position sur le marché. Le drapeau"Positions : Reverse" est responsable de l'inversion des signaux. Drapeau intéressant'Positions : Close opposite' - si ce drapeau est mis à'true' avant d'ouvrir une position, cela garantit la suppression des positions opposées.Print log' imprime la journalisation étendue de toutes les opérations. Le paramètre'Freeze and StopsLevels Coefficient' définit un coefficient pour les niveaux d'arrêt et de gel pour les cas où ces niveaux sont égaux à zéro pour un symbole. Il est recommandé d'appliquer une valeur de "3".
Je vais écrire des principes que je recommande vivement à l'auteur pour qu'il prenne conscience de ce qu'est le programme. Contrairement aux dépliants de Kovalev, où une partie du matériel est correcte, une autre contient des erreurs grossières, et une autre est une spéculation générale avec le lecteur, ces principes sont TOUJOURS et 100% corrects, peu importe ce que vous écrivez dans MQL : conseillers experts, scripts, ou conseillers experts :
Premier principe. Tout programme en MQL gère les événements. Un événement est une notification qui contient des informations sur quelque chose, généralement sur quelque chose qui a changé. Par exemple, un nouveau tick est apparu ou notre ordre en attente a été exécuté. D'autres événements ne contiennent aucune information, ils se produisent simplement. Par exemple, l'événement "timer" peut appeler la fonction utilisateur avec une périodicité définie. Il n'informe pas l'utilisateur que quelque chose a changé. Il invoque simplement le code de l'utilisateur, il n'a donc pas besoin d'informations supplémentaires. De la définition de l'événement découlent plusieurs méthodes non triviales :
- La première implication est qu'une fois que nous recevons un événement, nous devons le traiter le plus rapidement possible. Il peut y avoir de nombreux événements, et les événements peuvent s'empiler dans une file d'attente. MeteTrader (pas notre programme) gère les événements. Pour ce faire, il utilise une ressource spéciale appelée flux. Cette ressource est très précieuse et limitée. Le thread appartenant à MetaTrader exécute généreusement notre code grossier, sous-optimal et lent écrit dans un script sur le CPU de notre PC. Si le traitement des événements ralentit le thread dans notre code, dans certains cas, d'autres programmes exécutés dans MetaTrader ne pourront pas s'exécuter correctement. Ils attendront que nous libérions le fil de nos calculs inutiles et exécuteront ensuite leur code sur le fil libéré.
- Il y a de nombreux événements. Nous pouvons nous occuper de plusieurs des événements disponibles ou d'un seul. Lorsque nous créons un script, il ne gère qu'un seul événement, OnStart, qui se produit une fois. Lorsque nous écrivons un conseiller expert, il peut gérer plusieurs événements à la fois. Cela signifie qu'il est inutile de faire entrer votre programme dans le paradigme "programmez ce livre". Au lieu de cela, nous devons simplement comprendre que le programme est un gestionnaire de certains événements. Ils peuvent être appelés dans n'importe quel ordre, ils peuvent ne pas être appelés du tout. Les événements sont indépendants les uns des autres. Ainsi, les parties du programme traitant ces événements ne dépendent pas les unes des autres. Ils sont non linéaires et non séquentiels.
(c'est tout pour le moment, je continuerai si j'en ai envie).voici le premier que j'ai reçu pour me porter chance :-)
Utilisez son expa comme modèle dans vos recherches - code compétent !
là et
.
и
Inverser et d'autres choses et connecter les bibliothèques standard dans le code au début pour simplifier la position d'ouverture fie - ETUDIER ET NE PAS SE SOUCIER. En outre, s'habituer à écrire du code standard - il y a l'indentation et tout le reste
L'indicateur"Positions : une seule" défini sur"true" permet au conseiller expert de ne pas avoir plus d'une position sur le marché. Le drapeau"Positions : Reverse" est responsable de l'inversion des signaux. Drapeau intéressant'Positions : Close opposite' - si ce drapeau est mis à'true' avant d'ouvrir une position, cela garantit la suppression des positions opposées.Print log' imprime la journalisation étendue de toutes les opérations. Le paramètre'Freeze and StopsLevels Coefficient' définit un coefficient pour les niveaux d'arrêt et de gel pour les cas où ces niveaux sont égaux à zéro pour un symbole. Il est recommandé d'utiliser la valeur '3'.
Bonjour Roman ! Merci pour cet exemple. J'ai souvent essayé de comprendre les codes écrits par Vladimir Karputov, mais pour moi, c'est toujours un niveau inaccessible. Un peu plus tard, lorsque j'aurai plus d'informations en tête, il est probable que je revienne sur ses codes. Mais merci pour le conseil !
Salutations, Vladimir.
Je vais écrire des principes que je recommande vivement à l'auteur pour qu'il prenne conscience de ce qu'est le programme. Contrairement aux dépliants de Kovalev, où une partie du matériel est correcte, une autre contient des erreurs grossières, et une autre est une spéculation générale avec le lecteur, ces principes sont TOUJOURS et 100% corrects, peu importe ce que vous écrivez dans MQL : conseillers experts, scripts, ou conseillers experts :
Premier principe. Tout programme en MQL gère les événements. Un événement est une notification qui contient des informations sur quelque chose, généralement sur quelque chose qui a changé. Par exemple, un nouveau tick est apparu ou notre ordre en attente a été exécuté. Il y a des événements qui n'ont aucune information mais qui se produisent tout simplement. Par exemple, l'événement "timer" peut appeler la fonction utilisateur avec une périodicité définie. Il n'informe pas l'utilisateur que quelque chose a changé. Il appelle simplement le code de l'utilisateur, il n'a donc pas besoin d'informations supplémentaires. De la définition de l'événement découlent plusieurs méthodes non triviales :
- La première implication est qu'une fois que nous recevons un événement, nous devons le traiter le plus rapidement possible. Il peut y avoir de nombreux événements, et les événements peuvent s'empiler dans une file d'attente. MeteTrader (pas notre programme) gère les événements. Pour ce faire, il utilise une ressource spéciale appelée flux. Cette ressource est très précieuse et limitée. Le thread appartenant à MetaTrader exécute généreusement notre code grossier, sous-optimal et lent écrit dans un script sur le CPU de notre PC. Si le traitement des événements ralentit le thread dans notre code, dans certains cas, d'autres programmes exécutés dans MetaTrader ne pourront pas s'exécuter correctement. Ils attendront que nous libérions le fil de nos calculs inutiles et exécuteront ensuite leur code sur le fil libéré.
- Il y a de nombreux événements. Nous pouvons nous occuper de plusieurs des événements disponibles ou d'un seul. Lorsque nous créons un script, il ne gère qu'un seul événement, OnStart, qui se produit une fois. Lorsque nous écrivons un conseiller expert, il peut traiter plusieurs événements à la fois. Cela signifie qu'il est inutile de faire entrer votre programme dans le paradigme "programmez ce livre". Au lieu de cela, nous devons simplement comprendre que le programme est un gestionnaire de certains événements. Ils peuvent être appelés dans n'importe quel ordre, ils peuvent ne pas être appelés du tout. Les événements sont indépendants les uns des autres. Ainsi, les parties du programme traitant ces événements ne dépendent pas les unes des autres. Ils sont non linéaires et non séquentiels.
(C'est tout pour le moment, je continuerai si j'en ai envie).Bravo Vasily, j'attends la suite, si ça ne te dérange pas de l'écrire ! Tout ce que vous m'avez dit était laconique et compréhensible pour moi !
Salutations, Vladimir.
Bien joué Vasily, j'attends avec impatience la suite, si cela ne vous dérange pas de l'écrire ! Tout ce que vous avez rapporté est concis et compréhensible pour moi !
Salutations, Vladimir.
On avance :
- Comme il y a beaucoup d'événements, il y a beaucoup de gestionnaires d'événements. Puisque les événements sont appelés de manière incohérente, leurs gestionnaires d'événements sont également appelés de manière incohérente. Comme les appels sont incohérents, les gestionnaires d'événements ne peuvent pas dépendre les uns des autres, et ils ne peuvent pas non plus dépendre des données des autres. La seule construction qui répond à ces exigences strictes est une fonction.
- Les fonctions ne peuvent pas dépendre les unes des autres. Si une fonction renvoie la somme a+b, et que la seconde renvoie le produit a*b, alors le résultat de ces deux fonctions ne dépendra pas de la séquence d'appels. Nous pouvons appeler la première fonction avec les arguments 3 et 5 et obtenir 8. Ensuite, appelez la deuxième fonction avec les mêmes arguments et obtenez 24. Puis échangez leurs appels. Les résultats seront les mêmes. La fonction d'addition renverra toujours 8 avec les arguments 3 et 5. La fonction de multiplication retournera toujours 24 avec les mêmes arguments.
- Il ressort clairement de ce qui précède que le gestionnaire d'événements ne peut être qu'une fonction. Si un nouvel événement de tic se produit, il est traité par la fonction OnTick. Si l'événement Start (un lancement unique du script) se produit, il est géré par la fonction spéciale OnStart.
- Cette fonction est universelle. Cette fonction peut gérer non seulement les événements. La fonction peut retourner quelque chose d'utile, par exemple l'heure actuelle. Une fonction peut effectuer des calculs complexes avec les arguments qui lui sont transmis et renvoyer le résultat final de ces calculs sous la forme d'une valeur unique. Enfin, une fonction peut être un fournisseur de données : Vous appelez la fonction et obtenez les données dont vous avez besoin, telles que des citations, à partir de celle-ci.
- En interne, MetaTrader se compose de milliers de fonctions, dont environ 1500 mille sont gentiment mises à la disposition des utilisateurs. Ces fonctions sont très utiles. Ils vous permettent de vérifier l'heure du système et d'obtenir les données d'un instrument qui vous intéresse. Les fonctions sont utilisées pour envoyer des ordres de transaction. Vous pouvez ouvrir le manuel ICL et voir qu'il est constitué de fonctions et de leurs arguments. Ainsi, MetaTrader, en ce qui concerne les programmes utilisateurs, est un grand ensemble de fonctions.
- Les fonctions universelles ne suffisent pas. Quel que soit le nombre de nouvelles fonctions ajoutées au système, il y aura toujours une pénurie de celles-ci. La raison en est que chacun a des besoins différents. Il n'existe pas de dispositif unique pour toutes les occasions. Les fonctionnalités les plus génériques et universelles sont déjà incluses dans MetaTrader et sont aimablement partagées avec nous. Cependant, les besoins des utilisateurs sont infinis. MetaQuotes ne peut pas répondre aux besoins individuels de 100 000 utilisateurs de son terminal. Au lieu de cela, ils ont opté pour une solution plus souple : ils ont laissé les utilisateurs créer eux-mêmes les fonctionnalités qu'ils souhaitaient. Les utilisateurs en ont profité. Au lieu d'utiliser une fonction système qui ne leur convient pas, ils peuvent écrire leur propre fonction qui résout parfaitement leur problème. Aucune fonction du système n'est parfaite en raison de son universalité.
- La capacité d'un utilisateur à écrire ses propres fonctions et à comprendre leur fonctionnement vous indique le niveau de compétence du programmeur. S'il comprend qu'un programme est un ensemble disjoint de gestionnaires (sous forme de fonctions) qui ne traitent pas de manière cohérente les événements entrants, il est bon. S'il sait écrire ses propres fonctions, c'est un autre plus. S'il peut combiner le travail de plusieurs fonctions (les siennes et celles du système) dans un algorithme commun, c'est un autre atout pour lui.
- Si vous comprenez que tout dans MetaTrader (le quatrième et le cinquième) est en quelque sorte basé sur des fonctions, des fonctions et des fonctions - tout devient soudainement clair. L'aide n'est plus présentée comme un livre épais contenant un tas d'extraits de code éparpillés, mais comme un guide des fonctions disponibles et de ce qu'elles font. Tout le reste, comme les types de données, les tableaux, les structures, les classes, n'est pas pertinent. Il s'agit de soutenir les fonctions afin qu'elles puissent rendre quelque chose et accepter quelque chose.
(c'est tout pour le moment)Un débutant est inondé d'informations inutiles).
Cela suggère que vous ne devriez pas étaler vos désirs de cette manière. Vladimir aurait tout aussi bien pu poser des questions portant spécifiquement sur telle ou telle fonction et recevoir des conseils utiles, plutôt que les inepties des "experts" comme apprendre le C++ ou apprendre l'assembleur. Vous pourriez commencer par étudier les cartes perforées.