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

[hini]

Nikolai Semko # :

Bien Ok vous n'avez pas fourni ce fichier, c'est pourquoi je fais des suppositions. Attendons la version avec tous les fichiers pour pouvoir le tester en direct.

J'ai lu attentivement votre conversation à travers le traducteur, Nikolay Semko, je pense que vous avez raison, j'espère que mes mots n'offenseront pas l'auteur, vos compétences en programmation sont excellentes.

La meilleure façon de gérer les événements est d'utiliser une implémentation de pointeur qui sépare le fichier Internal_API.mqh créé par le moteur.

Lorsqu'un bouton est enfoncé ou relâché, il s'agit de deux événements. Le moteur peut générer une fonction pour le bouton, telle que setButton1Click(void* ptr), puis l'appeler dans l'événement : ptr() du bouton, cette chaîne "setButton1Click(void* ptr)" est appelée par l'utilisateur. Dans son EA, le ptr est un pointeur vers la fonction, entièrement explicitée dans le fichier de l'utilisateur, de sorte que Internal_API fonctionnera toujours correctement, mais n'a pas besoin d'être modifié.

C'est ce que j'ai compris, quoi qu'il en soit, j'attends toujours le chef-d'œuvre de l'auteur.

[hini]

Je ne sais pas si vous allez ouvrir le moteur GUI, si c'est le cas, je pense que quelqu'un collaborera pour améliorer ce projet, si ce n'est pas le cas, je peux tout à fait le comprendre, c'est votre travail.

[hini]

Si j'écris une grande partie de mon propre code de traitement dans Internal_API, lorsque je modifie l'interface graphique, que j'ajoute à nouveau des boutons et que je génère Internal_API, cela signifie-t-il que je dois copier le code de l'ancienne Internal_API dans le nouveau fichier Internal_API ?

[Roman Shiredchenko]

Essayez de transformer un article en un format digeste.... et fournissez le matériel dans son intégralité - pour le rendre plus intéressant.....

[Реter Konow]

hini projet, si ce n'est pas le cas je peux totalement le comprendre, c'est votre travail.

Le moteur et le Builder seront open source et chacun pourra y apporter les modifications qu'il souhaite, bien que je ne recommande pas de le faire sans une compréhension approfondie de leur fonctionnement.

Le moteur est essentiellement une petite copie du constructeur. Pour des raisons de commodité de connexion, il est placé dans un seul fichier. Le moteur contient les mécanismes nécessaires au fonctionnement des contrôles et des fenêtres, mais pas ceux qui sont responsables de la création d'une interface graphique conformément aux instructions du code de balisage. Il accepte les événements de la fonction OnChartEvent() du conseiller/indicateur de l'utilisateur et met en œuvre les réactions et le comportement de l'interface graphique.

[Реter Konow]

hini interface graphique, que j'ajoute à nouveau des boutons et que je génère Internal_API, cela signifie-t-il que je dois copier le code de l'ancienne Internal_API dans le nouveau fichier Internal_API ?

En partie, oui. La modification de l'interface graphique peut être différente. Par exemple, si vous modifiez quelques éléments décoratifs de l'interface sans ajouter de nouveaux éléments (c'est important), vous n'avez pas besoin d'imprimer un nouveau fichier Internal_API. Mais si vous créez de nouveaux éléments, fenêtres, tableaux, ou si vous les renommez, le fichier API doit être corrigé ou remplacé en copiant le code de l'ancien vers le nouveau. En principe, ce n'est pas très difficile, mais cela dépend du nombre de modifications apportées. Par conséquent, il est conseillé de terminer l'interface dans le constructeur en premier lieu, afin de ne pas avoir à effectuer ce travail à plusieurs reprises.

[Реter Konow]

Roman Shiredchenko #:

Essayez de transformer un article en un format digeste.... et fournissez le matériel dans son intégralité - pour le rendre plus intéressant.....

S'il y a un intérêt public, oui.

[hini]

Реter Konow #:
En partie, oui. La modification de l'interface graphique peut être différente. Par exemple, si vous modifiez certains éléments décoratifs de l'interface sans ajouter de nouveaux éléments (c'est important), vous n'avez pas besoin d'imprimer un nouveau fichier Internal_API. Mais si vous créez de nouveaux éléments, fenêtres, tableaux, ou si vous les renommez, le fichier API doit être corrigé ou remplacé en copiant le code de l'ancien vers le nouveau. En principe, ce n'est pas très difficile, mais cela dépend du nombre de modifications apportées. C'est pourquoi il est conseillé de terminer l'interface dans le concepteur en premier lieu afin de ne pas avoir à effectuer ce travail à plusieurs reprises.

Il est difficile de concevoir l'interface à l'avance, et il n'est pas rare d'améliorer l'interface pendant que l'on travaille dessus, parfois en supprimant un élément, ou en ajoutant quelque chose.

[Реter Konow]

hini #:
Il est difficile de concevoir l'interface à l'avance, et il n'est pas rare d'améliorer l'interface pendant que l'on travaille dessus, parfois en supprimant un élément, ou en ajoutant quelque chose.

Comme je l'ai dit précédemment, il n'est pas difficile de modifier le fichier API en cas de besoin. Il suffit de copier les blocs d'appels de fonctions de l'ancien fichier et de les insérer dans le nouveau. En fait, c'est facile. Surtout avec l'aide d'un éditeur de texte. Mais ME suffira sûrement.

D'après mon expérience, cela n'a jamais posé de problème. ))

[hini]

Реter Konow #:
Comme je l'ai déjà dit, il n'est pas difficile de modifier le fichier API si nécessaire. Il suffit de copier le bloc d'appel de fonction de l'ancien fichier et de l'insérer dans le nouveau fichier. C'est en fait assez simple. Surtout avec l'aide d'un éditeur de texte. Mais ME est sûrement suffisant.

D'après mon expérience, cela n'a jamais posé de problème.))

OK, j'ai compris. J'attends votre version !