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
Peter, tu peux me traiter comme tu veux, c'est ton droit, mais prends conseil auprès d'un camarade un peu plus expérimenté.
Le fichierGUI_DRIVE.mqh est connecté en premier dans le code. Rien n'est déclaré avant elle.
Si vous le compilez, vous obtiendrez une erreur de G_CORE manquant, et c'est logique car le tableau n'est pas déclaré dans ce fichier !
Conclusion ? La conclusion est élémentaire : le tableau doit être déclaré dans ce fichier. Au final, c'est ce fichier qui opère avec ce tableau, car ce fichier est le "moteur" ! Par conséquent, la déclaration du tableau lui-même dans celui-ci est correcte, selon le contexte d'utilisation.
Le fichier suivant,CORES.mqh , remplit le tableau avec la description des éléments du formulaire.
Bien sûr, lors de la compilation de l'EA lui-même avec ces fichiers, si le tableau est déclaré dans le premier fichier, il n'y aura aucun problème de compilation, car lorsque vous compilez le deuxième fichier, le tableau sera déjà visible dans le contexte du programme.
Mais ce que nous disons, c'est que chaque fichier doit être compilé sans erreur. Puisque le deuxième fichier remplit le tableau G_CORE avec des éléments, nous rencontrerons tout naturellement une erreur lors de la compilation de ce fichier, si le tableau n'est pas déclaré.
Et ici, nous utilisons, comme l'a dit Alexandre, une souche.
Pyotr, tu es un grand fan des définitions, donc tu sauras ce qui se passe.
Dans le fichier GUI_DRIVE vous déclarez un tableau global d'éléments du noyau G_CORE, après quoi le fichier devrait compiler sans erreurs.
Ensuite, dans ce fichier, vous ajoutez une définition.
#define __DRIVE__
Passez au fichier Cores. Avant de déclarer un tableau, utilisez le préprocesseur de compilation.
Et ensuite vous remplissez le tableau. Bien sûr, vous devrez changer un peu la façon dont vous remplissez le tableau, pour le faire sans déclaration.
Je pense que vous avez compris l'essentiel : si le fichier CORES est compilé, la valeur par défaut__DRIVE__ disparaît et le code de déclaration des tableaux est compilé et tout fonctionne bien.
Si le fichier est compilé dans le cadre de l'EA, alors après la compilation du premier fichier, la définition est déclarée et dans le second fichier, le tableau n'est pas déclaré parce que le compilateur "coupe" ce morceau de code.
J'espère vraiment que j'ai été clair.
Je le répète encore une fois : chaque fichier doit être compilé sans erreur. Si vous avez des dépendances, vous devez prévoir correctement leur emplacement et ajouter des processeurs de recompilation si nécessaire.
Lorsque chaque fichier est compilé sans erreur, vous avez davantage confiance dans l'intégrité de l'ensemble du système.
N'oubliez pas non plus d'ajouter une propriété dans chaque fichier :
Cette propriété permet un contrôle plus strict du code.
Oui, en manipulant le préprocesseur, vous pouvez faire en sorte que chaque fichier compile séparément sans erreur.
Certains camarades sont en train d'écrire un logiciel séparé qui modifie légèrement l'interface du méta-éditeur lui-même - pour la facilité d'utilisation uniquement !
Cette norme revient à utiliser un clavier - au lieu de taper des lettres en morse à travers un grincement. Les stubs ne changent rien, si ce n'est de passer constamment d'un fichier à l'autre au moment de la compilation. Mais un stub c'est 2 lignes de code. Combien de temps nous passerions sur cette navigation juste pour appuyer sur un bouton. Et combien de fois nous retournerons le 7 et ce qui deviendra plus rationnel afin de ne pas gaspiller nos vies à taper des lettres à travers un grincement.
Notez que nous ne parlons pas d'objets ou de classes, nous parlons simplement de gagner du temps. Votre temps... Et vous pouvez trouver une norme pour les rédiger vous-même.Sans parler du codage en russe, qui est par défaut discriminé par l'environnement de développement en anglais. Devrais-je aussi m'adapter et laisser à mon cerveau un maigre 30 % de performance, alors que je peux utiliser tous les 100 % en russe ?
Les professionnels utilisent leurs propres types de données dans leur code. En général, la langue dans laquelle ils sont rédigés n'a pas d'importance.
Mais si une fonction attend un nombre entier dans cet ordre : Accepter (largeur, hauteur).
Au lieu de cela, nous mélangeons accidentellement les deux et écrivons
Accepter (hauteur, largeur) - alors le copieur lui-même dit que nous avons une confusion ici. Que cela fonctionne pour vous - ce n'est pas non plus une question de langue ou d'objets. Il s'agit juste de ne pas avoir à rechercher cette erreur par vous-même.
Dans le code professionnel, les individus utilisent leurs propres types de données. La langue dans laquelle ils sont rédigés n'a pas vraiment d'importance.
Mais si une fonction attend un nombre entier dans cet ordre : Accepter (largeur, hauteur).
Au lieu de cela, nous mélangeons accidentellement les deux et écrivons
Accepter (hauteur, largeur) - alors le copieur lui-même dit que nous avons une confusion ici. Que cela fonctionne pour vous - ce n'est pas non plus une question de langue ou d'objets. Il s'agit simplement de ne pas avoir à rechercher cette erreur par soi-même.
Peter, tu peux me traiter comme tu veux, c'est ton droit, mais suis les conseils d'un camarade un peu plus expérimenté.
.......
N'oubliez pas non plus d'ajouter une propriété dans chaque fichier :
Cette propriété permet un contrôle plus strict du code.
c'est pour 5 - c'est toujours la même chose là-bas !
bien qu'en général je sois d'accord : un grand nombre d'avertissements à la compilation n'augmente pas la confiance dans le code.
c'est fait pour cinq - c'est toujours strict !
bien que je sois d'accord en général : un grand nombre d'avertissements au moment de la compilation n'augmente pas la confiance dans le code.