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

Nouveau commentaire
 
Le répertoire est toujours en russe ...... J'espère qu'il est possible d'avoir le répertoire et les noms de fichiers en anglais comme KIB PROJECTS ...... C'est une petite demande de ma part !
  
#include<(2)  KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh>

Le projet de démonstration 1 est inclus dans (1) KIB-source v1, mais pourquoi ne vois-je pas la fenêtre correspondante sur le diagramme ?

 
hini #:
Le catalogue est toujours en russe ...... J'espère qu'il est possible d'avoir le catalogue et les noms de fichiers en anglais comme KIB PROJECTS ....... C'est une petite demande de ma part !
Bien sûr, je traduirai les catalogues en anglais avant de les télécharger sur kodobase. Mais je n'ai pas encore eu le temps. Il s'agit d'une version provisoire destinée à être testée par le public.
 
hini #:

Le projet de démonstration 1 est inclus dans (1) KIB-source v1, mais pourquoi je ne vois pas la fenêtre associée dans le diagramme ?

C'est étrange. Je vais vérifier maintenant.
 
hini #:

Le projet de démonstration 1 est inclus dans (1) KIB-source v1, mais pourquoi je ne vois pas la fenêtre associée dans le diagramme ?

J'ai vérifié l'assemblage. Demo-project 1.mqh se trouve ici :

(2) KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh


 
Je ferai une analyse complète de la sortie un peu plus tard.
 

Hier, après avoir téléchargé la nouvelle version, après beaucoup de travail et sous le coup de l'émotion, j'ai écrit un billet très positif faisant littéralement l'éloge des nouvelles fonctionnalités. Un tel enthousiasme n'est pas très approprié dans le contexte d'une discussion technique stricte. Aujourd'hui, je souhaite examiner les solutions mises en œuvre d'une manière calme et impartiale. J'accueillerai volontiers les critiques constructives et les évaluations objectives. Il est important pour moi de connaître le point de vue des utilisateurs tiers. Le retour d'information permettra d'apporter des ajustements et des améliorations. Et bien sûr, à détecter et à corriger les bogues.

 
Passons maintenant à la répartition de la libération.
 
Je commencerai par une nouvelle page afin que les informations importantes restent visibles plus longtemps.
 


La tâche consistait à mettre en œuvre l'interaction programmatique du code utilisateur avec l'interface graphique du programme.

L'idée est la suivante :

  • Après avoir écrit et débogué le code KIB, l'utilisateur obtient le résultat souhaité (sous la forme de fenêtres prêtes) et enregistre le projet.
  • Le résultat de la génération est constitué de deux fichiers : UIDATA.mqh et API.mqh. Le premier est nécessaire pour le chargement et le fonctionnement de l'interface, le second pour fixer les événements des éléments.
  • L'utilisateur transfère les deux fichiers du dossier Files vers son projet (actuellement : KIB PROJECTS\(5) USER PROJECTS\Project 1).
  • Il compile son Expert Advisor ou son indicateur avec les lignes reliant le moteur et les deux fichiers :
//+------------------------------------------------------------------+
#include<(1)  KIB 1.0\(4) CONNECTIONS\KIB-DRIVE CONNECTIONS.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\UIDATA.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\API.mqh> 
//+------------------------------------------------------------------+
  • Lance l'EA sur le graphique et voit l'interface.
L'EA Shell v1.mq5 est utilisé comme exemple dans le projet de démonstration , qui "représente" un programme utilisateur. Il possède les mêmes connexions que celles nécessaires à l'analogue de l'utilisateur .

//----------------------------------------------------------------------------------

Toutefois, avant cette version, l'utilisateur ne pouvait recevoir les événements des éléments interactifs que dans un fichier API sous-clé.

Il est important de souligner que l'utilisateur ne disposait pas de nombreuses fonctions logicielles absolument essentielles.

Je vais les énumérer :

  • Ouverture/fermeture programmée des fenêtres de l'interface graphique.
  • Obtenir/définir des valeurs dans les paramètres de différents types d'éléments.
  • Changer l'état des éléments de manière programmatique: par exemple, activer/désactiver, verrouiller/déverrouiller des éléments lors d'actions de l'utilisateur ou d'événements externes fixés par l'Expert Advisor/indicateur en cours d'exécution.
  • Obtenir/régler par programme d'autres valeurs des propriétés de l'élément : base, texte, couleur du cadre. Modifier l'icône.


Cette mise à jour résout la quasi-totalité des problèmes posés.



Permettez-moi de les énumérer :.
  • L'utilisateur peut ouvrir/fermer les fenêtres de l'interface graphique par appel de programme.
  • L'utilisateur peut obtenir/définir des valeurs dans les paramètres des éléments qui en sont dotés. Y compris les éléments non interactifs tels que les cellules de tableau (CELL) et les étiquettes de texte avec un paramètre (VALUE).
  • Le programme permet de passer de deux à quatre états pour différents types d'éléments. Pour les boutons et les cases à cocher, quatre états de commutation logicielle sont disponibles (activé/désactivé/verrouillé activé/désactivé), pour les autres éléments - deux (verrouillé/déverrouillé).
  • De petits ensembles de propriétés d'éléments individuels sont disponibles pour les valeurs de retour/réglage du programme. Chaque ensemble est représenté par un préfixe qui s'ouvre sur une liste intellisense. Il généralise un petit groupe d'éléments apparentés ayant des propriétés similaires. Cette approche permet d'éviter toute confusion dans la multitude de propriétés des différents types d'éléments.
  • La définition programmatique d'une valeur pour un paramètre envoie l'événement à l'emplacement de l'élément dans le fichier API, où l'utilisateur peut écrire du code supplémentaire pour le gérer.
  • Les cellules des tableaux sont nommées automatiquement en pliant le nom de leur ligne et de leur colonne. Elles reçoivent un nom et une enveloppe fonctionnelle dans le fichier UIDATA.mqh. Cependant, elles ne sont pas présentes dans le fichier API parce qu'elles ne sont pas des éléments interactifs. Elles peuvent être trouvées dans la liste des éléments de la fenêtre et répondent aux commandes du logiciel comme tous les autres éléments.


Les possibilités de contrôle du programme permettent de réaliser des choses qui n'étaient pas disponibles auparavant :

1. Envoi de valeurs. Obtenir la valeur d'un élément et la transmettre à d'autres éléments dans la même fenêtre ou dans une autre fenêtre.

2. Ouverture logicielle de fenêtres d'avertissement et de dialogue. Par exemple, lorsqu'il est nécessaire d'afficher un message urgent ou une recommandation à un utilisateur.

3. Obtention d'une image générale des paramètres et de l'état d'exécution par le biais de requêtes sur les paramètres des éléments. Peut être utilisé en complément des analyses d'autres paramètres du programme.

4. Réinitialisation dynamique des paramètres du programme sans interrompre le processus de travail.

5. Grâce aux possibilités de changer les couleurs des bases, du texte et des cadres (pas encore de cadres), l'interface devient plus interactive et informative. Par exemple, lorsque vous rembobinez une valeur et qu'elle entre dans la zone de risque, le champ de saisie avec les boutons peut signaler à l'utilisateur le danger par la couleur rouge de sa base ou de son texte. Cette fonctionnalité est désormais facile à mettre en œuvre. Il en va de même pour la barre de défilement. Dans la zone des valeurs dangereuses, vous pouvez modifier par programme la couleur de la barre. Il s'agit d'un outil interactif, informatif et pratique.


Pour l'instant, je n'ai pas encore réalisé toutes les possibilités qui s'offrent à moi et je suis sûr qu'il y en a encore beaucoup d'autres à venir.


Passons maintenant à la partie pratique de la mise en place de la nouvelle version.


1...5253545556575859606162
Nouveau commentaire