Galerie d'interfaces utilisateur écrites en MQL - page 24

Nouveau commentaire
 
hini #:
Comment se débarrasser de plus de cinq mille avertissements générés lors de la compilation, dont un grand nombre dans les fichiers de langage de balisage ?
Vous ne pouvez pas le faire. C'est techniquement inévitable parce que nous écrivons du code de balisage dans le tableau de chaînes de caractères. Ce type de données est conventionnellement adapté à l'écriture de valeurs et de mots quelconques.

En fin de compte, cela n'a pas d'importance, car le constructeur est parfaitement capable de faire la distinction entre les mots-clés, les noms et les valeurs numériques.

Cette approche n'entraîne aucune perte de données.
 
Théoriquement, vous pourriez écrire (int) ou (double) avant chaque valeur numérique, mais je laisse cette possibilité à l'utilisateur.
 
Nous devons "marcher sur les plates-bandes du compilateur", mais à la fin nous gagnons). Ce n'est pas très grave.


Pour mémoire, je respecte les règles de programmation et les avertissements du compilateur. Je respecte les règles de programmation et les avertissements du compilateur, mais dans ce cas, je n'ai pas trouvé de meilleure solution. Je me rends compte que certaines personnes n'aimeront peut-être pas cette approche, mais elle s'est avérée être la plus optimale. Et inoffensive.
 
J'espère vraiment que demain je pourrai poster une mise à jour et que ceux qui le souhaitent pourront enfin commencer à créer leur propre interface. Je ferai de mon mieux.
 
Реter Konow avertissements du compilateur, mais dans ce cas, je n'ai pas trouvé de meilleure solution. Je me rends compte que certains n'apprécieront peut-être pas cette approche, mais elle s'est avérée être la plus optimale. Et inoffensive.
Petite anecdote :

Lorsque la question s'est posée de savoir où écrire le code de balisage, j'ai été confronté à deux options principales : dans un tableau de chaînes ou dans un fichier. Après avoir pesé le pour et le contre qui me venaient à l'esprit, j'ai décidé qu'un tableau était bien meilleur pour un certain nombre de raisons. Premièrement, l'initialisation et le traitement instantanés du contenu du tableau par le code constructeur. Deuxièmement, l'accès rapide aux attributs individuels et aux propriétés des contrôles à partir du constructeur/moteur pour la lecture/l'écrasement si nécessaire (avec un fichier, ce serait un énorme problème). Et troisièmement, il est beaucoup plus facile d'envoyer un tableau à une ressource via un événement personnalisé OnChartEvent(). C'est pourquoi nous avons choisi un tableau. Et les avertissements... Eh bien, qu'est-ce qu'on peut faire. Il faut toujours sacrifier quelque chose pour atteindre l'objectif.

 
Correction du texte ci-dessus : l'avancement ne se fait pas par ressource, mais par tranches de cordes composées.
 
Et la raison totale qui mettra le dernier clou dans le "couvercle du cercueil" de l'idée que le balisage pourrait être écrit dans un fichier texte :

Un fichier .txt ne peut pas être compilé pour s'assurer qu'il n'y a pas de fautes de frappe grossières. Cela signifie que si l'utilisateur commet une grave erreur avec des virgules, des guillemets, des espaces, etc., il ne le saura pas grâce au compilateur.

Ce n'est qu'après avoir échoué dans la construction de l'interface qu'il devra se rendre compte qu'il a mal tapé le code et aller à l'intérieur pour chercher et trouver la moindre coquille. S'il en manque ne serait-ce qu'une, la procédure doit être recommencée.

C'est un prix incroyablement élevé pour l'absence d'avertissements du compilateur.

C'est pourquoi, dans MQL, la variante avec un tableau de chaînes pour le code de balisage n'a pas d'alternative et ne peut pas être utilisée. Les avertissements du comp ilateur doivent être considérés comme une évidence.
 
P.S. Le compilateur avertit même lorsqu'un mot-clé est mal orthographié. Parfois, intellisense aide. Dans un fichier .txt, si les mots-clés sont mal orthographiés, vous ne le saurez pas. Il n'y a donc aucun avantage pratique à utiliser un fichier plutôt qu'un tableau.

J'espère avoir expliqué en détail pourquoi vous ne devriez pas vous débarrasser des avertissements du compilateur dans ce cas particulier.

Bonne journée à tous.

 
Реter Konow avertissements du compilateur ne devraient pas être supprimés dans ce cas particulier.

Bonjour à tous.

D'accord, j'ai compris.
 
Cette partie du code est-elle au cœur du constructeur ?
1...171819202122232425262728293031...70
Nouveau commentaire