Discussion de l'article "Contrôles graphiques personnalisés. Partie 1 : Création d'un contrôle simple"
Je me demande ce qui est prévu pour la deuxième partie.
L'idéologie va-t-elle changer ? ...J'ai vraiment besoin qu'elle change.
Peut-être devrions-nous commencer par la troisième partie - créer des formulaires avec vos contrôles.
puis passer à la partie suivante - le fonctionnement interne de chaque élément.
C'est-à-dire qu'il faut d'abord éduquer les utilisateurs sur la manière dont le complexe fonctionne dans son ensemble, sur la manière dont l'élément enfant échange des messages et des événements avec l'élément parent, sur la manière dont l'idéologie fonctionne en général. C'est important, car il est souhaitable de passer du général au particulier, c'est-à-dire aux subtilités de chaque élément spécifique.
D'ailleurs, il ne faut pas insister sur le dessin, c'est-à-dire sur la manière dont chaque élément est dessiné (vous pouvez le faire brièvement, mais tous les éléments sont dessinés par la fonction Show, de sorte que les utilisateurs sachent où regarder dans chaque classe pour voir le bloc de dessin). Le dessin n'est vraiment rien comparé à l'idéologie de l'ensemble du processus.
Il serait préférable de montrer des exemples de formulaires prêts à l'emploi dans lesquels tous les éléments sont liés.
C'est-à-dire, sur un exemple prêt à l'emploi, décomposer les spécificités.
L'idéologie va-t-elle changer ? ...J'ai vraiment besoin qu'elle change.
Peut-être aurions-nous dû commencer par la troisième partie, la création des moules.
et passer progressivement au fonctionnement interne de chaque élément.
Qu'est-ce que l'idéologie ?
Une forme n'est rien d'autre que des coordonnées x et y.
Si vous commenciez par un formulaire, qu'y écririez-vous - "ceci est un formulaire, et ici vous ajouterez un élément de contrôle, et ici vous traiterez son événement...", mais de quel type d'élément de contrôle s'agit-il, que représente-t-il - personne ne le sait.
Si vous créez un formulaire dans la deuxième partie, alors que nous n'avons qu'un seul élément de contrôle, ce n'est pas indicatif et ce n'est pas beau.
Qu'en est-il exactement de l'idéologie ?
La forme n'est essentiellement rien - des coordonnées x et y.
Expansion de la réponse juste au-dessus.
Vous avez raison. C'est justement cela, la forme n'est rien. Ce qui compte, c'est le processus d'échange d'événements et l'interaction de tous les éléments dans leur ensemble. Et cela ne peut être expliqué que si l'on démontre le fonctionnement du système dans son ensemble, et non élément par élément.
Si vous créez un formulaire dans la deuxième partie, alors que nous n'avons qu'un seul élément de contrôle, ce n'est pas indicatif et ce n'est pas beau.
J'ai développé la réponse ci-dessus.
Vous avez raison. La forme n'est rien. L'essentiel est le processus d'échange d'événements et d'interaction de tous les éléments dans leur ensemble.
Le formulaire et la classe de contrôle sont-ils prêts ?
Tout à fait. Au début, je l'ai fait sans sous-fenêtres, maintenant je suis en train de tout reconcevoir pour travailler dans des sous-fenêtres.
L'idéologie va-t-elle changer ? ...J'ai vraiment besoin qu'elle change.
Peut-être auriez-vous dû commencer par la troisième partie - créer des formulaires avec vos contrôles.
et passer ensuite à la partie suivante - le fonctionnement interne de chaque élément.
En d'autres termes, il faut d'abord apprendre aux utilisateurs comment le complexe fonctionne dans son ensemble, comment les messages et les événements sont échangés entre l'élément enfant et l'élément parent, comment l'idéologie fonctionne en général. C'est important, car il est souhaitable de passer du général au particulier, c'est-à-dire aux subtilités de chaque élément spécifique.
D'ailleurs, il ne faut pas mettre l'accent sur le rendu, c'est-à-dire sur la manière dont chaque élément est dessiné. Il est préférable de montrer quelques exemples du fonctionnement des formes et de la manière dont tous les éléments sont reliés. Le dessin n'est rien comparé à l'idéologie de l'ensemble du processus.
Ne me dites pas qu'il y a déjà suffisamment d'exemples de création de codes simples, mais vous ne pouvez pas créer une hiérarchie réussie de classes ou au moins un schéma facile à mettre en œuvre d'un produit universel, facilement transformable. Même les classes standard de MQ compliquent souvent l'écriture des programmes en prévoyant des possibilités à l'avance.
Le formulaire comportera un bouton OK et un bouton Annuler, ce qui permettra de sauvegarder les données en cas de redémarrage du terminal. Il y aura une gestion des événements, la possibilité de faire glisser le formulaire, de le minimiser.
OK. C'est très bien.
Si vous parlez des fonctions de haut niveau dans la deuxième partie, les composants de l'article seront utilisés plus rapidement.
Je commencerais toujours par le formulaire + les boutons (+ la boîte de saisie) et ne parlerais que dans la troisième partie des composants de contrôle spécifiques - listes, menus, etc.
Après tout, il s'agit d'enseigner comment écrire de tels contrôles. Mais tant qu'il n'y aura pas de formulaire où les insérer, l'article ne donnera pas un effet aussi spectaculaire et nécessaire.
En outre, dès que vous donnez Form+Button (je veux dire 3 sortes - radio, push, check) + EditBox dès le deuxième article, l'utilisateur verra les classes comme un tout et sera capable de créer ses propres contrôles de manière indépendante.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Un nouvel article Contrôles graphiques personnalisés. Partie 1 : Création d'un contrôle simple a été publié :
Cet article couvre les principes généraux de développement des contrôles graphiques. Nous allons préparer des outils pour un travail rapide et pratique avec des objets graphiques, analyser un exemple de création d'un champ simple de saisie de texte ou de données numériques ainsi que les manières de l'utiliser.
Il y a au total plus de quarante objets graphiques dans le terminal client MetaTrader 5. Tous ces objets peuvent être utilisés séparément, mais le plus souvent ils sont utilisés dans une chaîne d'objets interconnectés. Par exemple, lorsqu'un champ d'édition (OBJ_EDIT) est utilisé, une étiquette bitmap (OBJ_LABEL) est utilisée avec lui très souvent pour indiquer la fonction du champ d'édition.
Lorsque vous utilisez un champ d'édition, vous devez souvent vérifier l'exactitude des données saisies par un utilisateur et offrir la possibilité d'utiliser à la fois un point et une virgule comme séparateur décimal.
Lorsque vous utilisez une sortie de données par programmation, vous devez formater les données. Par exemple, vous devez supprimer les zéros inutiles. Ainsi, il serait plus facile d'avoir un seul objet qui inclut le champ d'édition, l'étiquette bitmap et quelques autres fonctionnalités opérationnelles.
Actuellement, il existe un certain ensemble de contrôles graphiques dans le monde de la programmation, qui est utilisé dans presque toutes les applications : un formulaire (la base d'une interface d'application, où se trouvent tous les éléments de contrôle), un cadre (il permet le regroupement et la séparation des ensembles d'éléments qui ont un objectif fonctionnel), un bouton, un champ d'édition, une étiquette, une case à cocher, des boutons radio, des barres de défilement verticales et horizontales, une liste, une liste déroulante, une ligne de menu, un onglet de menu (fig . 3).
Auteur : Dmitry Fedoseev