Besoin d'aide de la part des développeurs et programmeurs MT4 - page 7
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
Quel tas d'idioties...
Je pense également que le fait de boucler l'EA est un mauvais ton. Il est parfaitement logique de ne modifier les paramètres qu'après la fin du cycle de démarrage. Le topicstarter n'a pu s'empêcher de comprendre que le problème se situe dans sa boucle sans fin, car il n'est pas un amateur. Cependant, il n'a rien écrit dans le premier post sur la boucle infinie dans les Expert Advisors. Personnellement, je n'ai pas implémenté de tels systèmes dans mes EAs, mais à ma connaissance, à en juger par mes posts,cela ne s'est jamais produit auparavant- la fenêtre des paramètres dans les EAs bouclés n'était tout simplement pas ouverte. Cela signifie que la déclaration du CT"Cela entraîne une incompatibilité fondamentale des EA existants avec les nouvelles versions de MT4" n'est pas vraie - dans les anciennes versions de MT4, ces EA ne permettaient pas non plus de modifier les paramètres, car il était impossible d'ouvrir la fenêtre jusqu'à la fin du cycle.
EventSetMillisecondTimer résout le problème. Mais depuis combien de temps cette fonction est-elle apparue ? N'y avait-il pas juste EventSetTimer avant ? Avec un intervalle d'appel minimum d'une seconde, ce type d'événement est totalement inutile lorsque l'on écrit des systèmes pour le trading réel, où il peut y avoir des dizaines de ticks par seconde pour chaque symbole.
Il n'y a toujours pas de référence à cette fonction dans l'aide sur les minuteries! Je l'ai découvert par hasard, comme un indice en entrant dans l'EventSet.
Il y a cependant, à mon avis, un problème et une incohérence dans le nouveau MQL 4/5 : Lors de la désinitialisation et de l'initialisation, il n'y a pas de suppression et de recréation d'objets dynamiques dans les variables globales...
Il y a cependant, à mon avis, un problème et une incohérence dans le nouveau MQL 4/5 : la désinitialisation et l'initialisation ne suppriment pas et ne recréent pas les objets dynamiques dans les variables globales. Autrement dit, si des paramètres de l'EA sont lus dans les constructeurs d'objets créés dynamiquement dans des variables globales et que l'EA continue à travailler avec eux, lorsque les paramètres sont modifiés, l'EA continuera à fonctionner comme si les paramètres n'avaient pas changé. À mon avis, ce n'est pas logique et les variables globales devraient être désinitialisées après la désinitialisation de l'EA, puis réinitialisées avant l'initialisation de l'EA. Ce problème est actuellement résolu en plaçant l'initialisation et la suppression de ces variables dans OnInit et OnDeinit.
Oui, c'est un vrai râteau, surtout si l'on considère que la documentation (niici, nilà) ne souligne pas que le chargement n'est désormais plus lié 1 à 1 avec l'événement d'initialisation. Voici quelques mots comme ça :
Les variables globales sont initialisées une fois, immédiatement après le chargement du programme dans la mémoire du terminal client.
n'est manifestement pas suffisant pour signaler au développeur que les modifications ultérieures des paramètres seront désinitialisées et initialisées, MAIS PAS le déchargement et le chargement correspondants.
Oui, c'est un vrai râteau, surtout si l'on considère que la documentation (niici nilà) ne souligne pas que le chargement n'est désormais plus lié 1 à 1 avec l'événement d'initialisation. Voici quelques mots comme ça :
Les variables globales sont initialisées une fois, immédiatement après le chargement du programme dans la mémoire du terminal client.
n'est manifestement pas suffisant pour attirer l'attention du développeur sur le fait que les changements de paramètres ultérieurs désinitialiseront et initialiseront, MAIS N'EFFECTUERONT PAS les déchargements et chargements correspondants.
Il n'est pas nécessaire de charger/décharger et de réinitialiser les variables. Le programmeur doit s'occuper de l'initialisation des variables.
Il n'est pas nécessaire de charger/décharger et de réinitialiser les variables. Le programmeur doit s'occuper de l'initialisation des variables.
C'est ce que je veux dire : le moment où cette initialisation est effectuée n'est pas clair. Code avec une variable globale :
int x = 0;
c'est aussi une initialisation. Mais il n'est pas clairement écrit dans la documentation qu'il ne s'agit pas d'une initialisation du point de vue de MC.
Strictement parlant, il y a maintenant 2 initialisations différentes dans MT : l'une est effectuée au démarrage du programme et l'autre est effectuée lors du changement de "l'environnement" au moment de l'appel OnInit. La mauvaise chose est que cela doit être déterré.
Un démarrage à froid est effectué lorsque le programme est lancé. La mémoire est allouée aux variables et initialisée avec des valeurs initiales.
En marche - démarrage à chaud. Ici, le programmeur doit s'occuper de l'initialisation des variables et c'est bien.
Un démarrage à froid est effectué lorsque le programme est lancé. La mémoire est allouée aux variables et initialisée avec des valeurs initiales.
En marche - démarrage à chaud. Dans ce cas, le programmeur doit s'occuper de l'initialisation des variables et c'est une bonne chose.
Que ce soit bon ou mauvais est une question philosophique... Mais le fait qu'il y ait 0.0 information à ce sujet dans la documentation n'est pas bon...
Et, si je me souviens bien, une telle chose n'existait pas auparavant, c'est-à-dire qu'il s'agit, pour le moins, d'une "fonctionnalité" ajoutée spécialement pour la "commodité" des programmeurs, mais qui viole l'invariance des codes existants (écrits pour les règles d'initialisation précédentes). Ainsi, le principe immuable consistant à préserver la compatibilité de l'ancien code avec les nouvelles versions du logiciel dans la mesure du possible n'est pas respecté.
Personne n'est contre les nouvelles fonctionnalités et les optimisations. Mais pourquoi ne pas les faire de manière à ce que l'ancien code ne soit pas cassé ? En particulier, pour cette nouvelle initialisation, nous pourrions allouer une commande supplémentaire du préprocesseur similaire à #property strict. Par exemple, cela pourrait être #property lazyinit, et si elle est spécifiée par le développeur (c'est-à-dire explicitement, ce qui signifie qu'il est au courant de la nouvelle initialisation dans mql), alors nous nous réjouissons de l'optimisation. Et si ce n'est pas spécifié, alors nous sommes heureux que le code précédent fonctionne de manière cohérente, sans avoir à creuser et à chercher des endroits où les variables globales pourraient rester, qui doivent maintenant non seulement être déclarées, mais aussi initialisées séparément dans OnInit. Pour chacune de ces variables, il y aura 2 lignes de code au lieu d'une.