GUI à l'initiative de la foule. Test bêta ouvert. - page 48

Nouveau commentaire
 

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é.

#include <GUI_DRIVE.mqh>
#include "..\Files\CORES.mqh"
#include "..\Files\Internal_API.mqh"

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.

#ifndef __DRIVE__
int G_CORE[][prop_limit];
#endif

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 :

#property strict

Cette propriété permet un contrôle plus strict du code.

 
Cela n'a guère de sens pratique. Si chaque fichier se compile sans erreur, indépendamment de l'intégrité de l'assemblage global, l'utilisateur pourrait facilement manquer la connexion de l'un des fichiers. C'est facile d'oublier.

De toute façon, c'est tellement insignifiant que je ne perds pas mon temps avec ça. C'est un non-sens total. C'est un non-sens.
 
Oui, vous pouvez faire en sorte que chaque fichier soit compilé séparément sans erreur en manipulant le préprocesseur.

Mais c'est là que réside l'erreur. Ils sont les parties d'un tout et ne doivent pas "prétendre" être indépendants des autres parties. Et en effet, l'utilisateur peut décider que tous les fichiers ne sont pas nécessaires, car le système fonctionne tel quel.

Perdre du temps sur une telle activité qui a un sens très douteux ? Qui est-ce que j'essaie de tromper ? Le compilateur ?

Les camarades "expérimentés" semblent avoir peur de sa voix sévère et croient qu'elle a toujours raison en tout. Ils essaient donc de s'adapter, même si cela n'a pas de sens.

J'avais des milliers d'avertissements dans mon code de langage de balisage parce que je devais mettre (sring) avant les constantes. Je peux imaginer ce que serait le code si je mettais une conversion de type avant chaque nombre. Mais au moins, il n'y aurait pas d'avertissement.
 
Реter Konow:
Oui, en manipulant le préprocesseur, vous pouvez faire en sorte que chaque fichier compile séparément sans erreur.

Mais c'est là que réside l'erreur. Ils sont les parties d'un tout et ne doivent pas "prétendre" être indépendants des autres parties. Et en effet, l'utilisateur peut décider que tous les fichiers ne sont pas nécessaires, car le système fonctionne tel quel.

Perdre du temps sur une telle activité qui a un sens très douteux ? Qui est-ce que j'essaie de tromper ? Le compilateur ?

Les camarades "expérimentés" semblent avoir peur de sa voix sévère et croient qu'elle a toujours raison en tout. Ils essaient donc de s'adapter, même si cela n'a aucun sens.

J'avais des milliers d'avertissements dans mon code de langage de balisage parce que je devais mettre (sring) avant les constantes. Je peux imaginer ce que serait le code si je mettais une conversion de type avant chaque nombre. Mais au moins, il n'y aurait pas d'avertissement.

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 discriminé par défaut par l'environnement de développement en anglais. Et aussi de s'adapter et de laisser à mon cerveau un maigre 30% de performance, alors que je peux utiliser tous les 100% en russe ?

Voilà pour le prix du "professionnalisme".
 
Реter Konow:
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 ?

Voilà pour le prix du "professionnalisme".

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.

 
Alexandr Andreev:

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.

Il s'agit d'une branche permettant de tester des solutions prêtes à l'emploi et de les communiquer aux utilisateurs.

J'ai besoin de testeurs constructifs, pas de "professionnels" ambitieux qui cherchent quelque chose à redire.

Je ne vais pas discuter de questions abstraites. Avez-vous connecté le panneau assemblé, trouvé des bugs, les avoir signalés ? Merci beaucoup ! Faire le malin et s'en prendre à ce que l'on ne comprend pas - au revoir.
 
Messieurs les gens intelligents, vous n'avez rien à faire ici.

Pour ceux qui n'ont pas dirigé l'éditeur et n'ont pas connecté le panel, mais qui "enseignent", la conversation est courte.

Les autres, bienvenue !
 
Алексей Барбашин:

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 :

#property strict

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.

 
Igor Zakharov:

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.

Je vais retirer les avertissements. Temporairement.
1...414243444546474849505152535455...58
Nouveau commentaire