[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 371
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
celui-là :
... ou mieux encore, un de ceux-là :
... ou mieux encore, un de ceux-là :
Oui, je suis d'accord.
Je rassemble toutes mes suggestions dans l'"ancien" commentaire (s'il y en a). - Ce ne sera peut-être pas tout à fait "juste", mais ce ne sera pas éparpillé.
Je pense que le problème est l'accumulation de textes - reflété dans le commentaire principal (je ne sais pas comment faire le lien vers celui-ci - désolé).
3. Sortez l'appel de fonction de formation d'objet graphique de la boucle interne (frein principal).
Maintenant, je me demande aussi - Comment faites-vous cela ? (mise en œuvre)
Hm.... Exactement ! - Il est empilable. Et les valeurs intermédiaires ne sont pas importantes.
Alors il n'y en aura pas beaucoup...
J'ai cet appel dans ma fonction init :
Cette fonction ici :
Variables gd_spread, gd_stopLevel, gd_tickSize que j'ai déclarées globalement jusqu'à présent. Maintenant, j'ai décidé d'écrire des bibliothèques qui utilisent ces variables. Il s'avère que j'ai déplacé ces variables dans le fichier d'en-tête. Donc, pour éviter les erreurs à la compilation de la bibliothèque, je devrais transférer la fonctionGetMarketInfo() à la bibliothèque également, n'est-ce pas ?
J'ai cet appel dans ma fonction init :
Cette fonction ici :
Variables gd_spread, gd_stopLevel, gd_tickSize que j'ai déclarées globalement jusqu'à présent. Maintenant, j'ai décidé d'écrire des bibliothèques qui utilisent ces variables. Il s'avère que j'ai déplacé ces variables dans le fichier d'en-tête. Donc, pour éviter les erreurs à la compilation de la bibliothèque, je devrais transférer la fonctionGetMarketInfo() à la bibliothèque également, n'est-ce pas ?
Certainement pas dans l'unité - l'étalement et le nivellement d'arrêt peuvent changer au fil du temps.
Je pense que l'inite devrait être écarté, pour éviter les problèmes dans le commerce réel. Si la connexion est coupée par le DC, puis réapparaît, la réinitialisation n'aura pas lieu et cela provoque des erreurs et des problèmes dans le trading réel, n'est-ce pas ?
Eh bien, que devons-nous faire alors ? Appeler constamment une fonction dans chaque fonction qui renverra ces variables de marché ?
Je pense que l'init devrait être abandonné, afin qu'il n'y ait pas de dysfonctionnements dans le commerce réel. Après tout, si la connexion est coupée par le DC, puis réapparaît, la réinitialisation n'aura pas lieu, et cela provoque déjà des erreurs et des défauts lorsqu'on travaille dans le monde réel, non ?
Eh bien, que faire alors ? Appeler constamment une fonction dans chaque fonction, qui retournera ces variables de marché ?
Ce type d'information doit être divisé en deux catégories : modifiable et immuable.
Les données immuables peuvent être écrites n'importe où, car même en cas de rupture de connexion, les données seront toujours pertinentes. - Il vaut mieux, bien sûr, ne pas commencer, afin de ne pas accabler inutilement la chouette.
Mais les variables peuvent être soit appelées par une fonction (si la bibliothèque est utilisée), soit simplement mises à jour au début de la fonction de démarrage.
C'est aussi vrai. Le cerveau est toujours en train de penser à la productivité, à un moment où l'esprit ne sait pas vraiment comment s'y prendre. J'ai un tempérament... un jumeau :(
C'est vrai, vous devez séparer l'un de l'autre en une seule fois.
Mais encore une fois. Si les variables de l'environnement de marchégd_stopLevel,gd_tickSize sont utilisées dans différentes fonctions (fonctions de modification, d'envoi d'ordre, etc.), il n'est pas tout à fait raisonnable d'appeler la fonction qui obtient constamment les valeurs spécifiées dans la fonction de bibliothèque. Y a-t-il un moyen d'unifier tout cela ? Après tout, contrairement au spread, le stop loss et la taille du tick seront toujours les mêmes.
C'est aussi vrai. Le cerveau est toujours en train de penser à la productivité, à un moment où l'esprit ne sait pas vraiment comment s'y prendre. J'ai un tempérament... un jumeau :(
C'est vrai, tu dois séparer l'un de l'autre en une seule fois.
Mais encore une fois. Si les variables de l'environnement de marchégd_stopLevel,gd_tickSize sont utilisées dans différentes fonctions (fonctions de modification, d'envoi d'ordre, etc.), il n'est pas tout à fait raisonnable d'appeler la fonction qui obtient constamment les valeurs spécifiées dans la fonction de bibliothèque. Y a-t-il un moyen d'unifier tout cela ? Après tout, contrairement au spread, le stop loss et la taille du tick seront toujours les mêmes.
Artem a déjà dit que le stoplevel peut aussi flotter - ce n'est pas une valeur constante ! - Et la taille du tick est, oui, une constante.
Pour unifier - encore une fois, le diviser en 2 fonctions - MarketInfoConst et MarketInfoImage (variable). Placez-en un en Inite, l'autre au début de Start(s). Et il sera possible de les combiner en une bibliothèque.
La question de la productivité (optimisation des hiboux) est différente. Personnellement, je n'entasse pas toutes ces fonctions dans la chouette. Je prends juste les paramètres comme j'en ai besoin. Oui, je dois écrire plus de code, mais Owl gère moins d'éléments de bibliothèque "superflus", car tout ce qui se trouve dans MarketInfo ne s'avère pas forcément nécessaire dans Owl.Artem a déjà dit que le niveau d'arrêt peut aussi flotter - ce n'est pas une constante ! - Et la taille de la tique est, oui, une constante.
Et d'une manière ou d'une autre, je n'y ai pas pensé, que stollevel n'est pas une valeur constante. Fidèle à ses habitudes.
La question de la productivité (optimisation des hiboux) est différente. Personnellement, je n'entasse pas toutes ces fonctions dans la chouette. Je prends juste les paramètres comme j'en ai besoin. Oui, je dois écrire plus de code, mais Owl gère moins d'absurdités de bibliothèque "inutiles", parce que tout ce qui se trouve dans MarketInfo peut ne pas s'avérer nécessaire dans Owl.
Oui, si vous obtenez un tas de variables d'environnement différentes à travers une fonction, ce n'est pas une option non plus. Apparemment, il est plus facile d'obtenir ces données en fonction des besoins avant d'effectuer des calculs dans une fonction spécifique.