Discussion de l'article "Le MQL5 Cookbook : Commandes de la sous-fenêtre d'indicateur - Boutons"

[MetaQuotes]

Un nouvel article Le MQL5 Cookbook : Commandes de la sous-fenêtre d'indicateur - Boutons a été publié :

Dans cet article, nous examinerons un exemple de développement d'une interface utilisateur avec des commandes de bouton. Pour transmettre l'idée d'interactivité à l'utilisateur, les boutons changeront de couleur lorsque le curseur les survolera. Avec le curseur sur un bouton, la couleur du bouton sera légèrement assombrie, devenant nettement plus sombre lorsque le bouton est cliqué. De plus, nous ajouterons des info-bulles à chaque bouton, créant ainsi une interface intuitive.

Veuillez noter le dernier paramètre de la fonction CreateButton() : il est responsable de l'info-bulle lorsque le curseur de la souris passe sur un objet graphique. Par exemple, dans la fonction AddButtonsPanel() ce paramètre est représenté par les valeurs passées du tableau button_texts (texte affiché sur les boutons). Vous pouvez créer un tableau séparé avec des descriptions plus détaillées, si vous le souhaitez.

Maintenant, si vous attachez l'indicateur au graphique, le résultat sera le suivant :

Fig. 1. Boutons ajoutés à la sous-fenêtre de l'indicateur

Auteur : Anatoli Kazharski

[Vasiliy Sokolov]

Bon article pour les débutants. Cependant, dans les interfaces plus complexes, cette approche n'est plus acceptable. La première chose qui attire l'attention :

for(int i=0; i<BUTTON_COLUMNS; i++)
     {
      for(int j=0; j<BUTTON_ROWS; j++)
        {
            ...
      ...
...

C'est-à-dire qu'une structure de tableau rigide est cousue dans l'algorithme et cette construction se retrouve dans presque toutes les fonctions. Imaginons maintenant que la sous-fenêtre contienne plusieurs éléments graphiques qui ne sont aucunement liés au tableau. Pour eux, nous devrons décrire leur propre modèle de positionnement, ce qui n'est pas une bonne chose. Le modèle de positionnement doit être unique et universel, c'est-à-dire que dans ce cas, la présentation "tableau" doit être un cas particulier de ce modèle.

[Anatoli Kazharski]

C-4:

Bon article pour les débutants. Cependant, dans les interfaces plus complexes, cette approche n'est plus acceptable. La première chose qui attire l'attention :

C'est-à-dire qu'une structure de tableau rigide est cousue dans l'algorithme et cette construction se retrouve dans presque toutes les fonctions. Imaginons maintenant que la sous-fenêtre contienne plusieurs éléments graphiques qui ne sont aucunement liés au tableau. Pour eux, nous devrons décrire leur propre modèle de positionnement, ce qui n'est pas une bonne chose. Le modèle de positionnement doit être unique et universel, c'est-à-dire que dans ce cas, la présentation "tableau" doit être un cas particulier de ce modèle.

Oui, vous avez raison. J'essaierai de trouver quelque chose de plus original la prochaine fois. )

Dans ce cas, pour s'affranchir du cas particulier, il suffit d'utiliser un tableau à une dimension et une boucle.

[Andrey Khatimlianskii]

Je ne comprends pas pourquoi il faut utiliser OBJ_EDIT.

Il aurait été beaucoup plus utile de faire "revivre" les boutons standards de la bibliothèque (pour qu'ils brillent aussi sous la souris).

En d'autres termes, cet article semble utile, mais je ne comprends pas pourquoi une telle méthode a été choisie.

ps : j'envie la fécondité de l'auteur ;)

[Anatoli Kazharski]

komposter:

...

J'ai déjà l'habitude d'utiliser OBJ_EDIT, car il est affiché lors de la visualisation dans le testeur.

Dans ce cas, vous pouvez utiliser n'importe quel objet pour l'exemple. Il s'agit d'un processus créatif, après tout. )

[Vasiliy Sokolov]

komposter:

Je ne comprends pas pourquoi vous devriez utiliser OBJ_EDIT.

Il serait beaucoup plus utile de faire "revivre" les boutons standard de la bibliothèque (afin qu'ils brillent également sous la souris).

En d'autres termes, cet article semble utile, mais je ne comprends pas pourquoi une telle méthode a été choisie.

ps : j'envie la fécondité de l'auteur ;)

En réalité, les boutons standards sont des éléments de contrôle très glissants, car en premier lieu ils ne supportent pas la couleur du cadre (bien qu'il soit très étrange de savoir pourquoi), et en second lieu, en fonction du type de cadre BORDER_FLAT, BORDER_RAISED visuellement positionné clairement en dehors de son emplacement, je ne dis pas qu'en plus cela change leur ombre en fonction de l'état de l'appui et très lent à changer son affichage sans ChartRedraw. En réalité, le bouton, hormis son interface hachée à la Windows 3.11, n'apporte aucun avantage par rapport aux autres éléments. Certes, il existe un champ spécial OBJ_SELECTED, qui indique si le bouton est enfoncé ou non, mais en réalité, il n'y a aucun problème à créer son propre objet OBJ_EDIT, qui contient l'indicateur d'enfoncement.

[Vasiliy Smirnov]

Et les boutons ne sont pas du tout des boutons).

[Vasiliy Sokolov]

komposter:

Il serait beaucoup plus utile d'"animer" les boutons standard de la bibliothèque (pour qu'ils brillent également sous la souris).

Et je me demande s'il y a un seul développeur professionnel qui utiliserait la bibliothèque standard d' éléments graphiques dans ses produits ?

[Anatoli Kazharski]

zfs:
Et les boutons ne sont pas vraiment des boutons).

Un bouton, c'est tout ce qu'on peut pousser. ))

[Anatoli Kazharski]

C-4:
Et je me demande s'il existe un développeur professionnel qui utiliserait la bibliothèque standard d' éléments graphiques dans ses produits ?

Je pense qu'il existe sur le marché des produits dont les interfaces comportent des éléments qui ressemblent à ceux utilisés dans la bibliothèque standard.

[Sergey Pavlov]

Je me demande si, lorsque vous avez préparé le matériel, vous avez lu cet article.