Galerie d'interfaces utilisateur écrites en MQL - page 42
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Ajouté :
Les fenêtres de menu restent désormais toujours à l'intérieur de l'espace graphique et ne sortent pas de la vue. Exemple :
NE PAS DÉPASSER LE BORD DROIT DU GRAPHIQUE :
NE PAS DÉPASSER LE BORD INFÉRIEUR DU GRAPHIQUE :
L'absence d'orientations prioritaires en matière de développement n'aboutit jamais à de bons résultats. Une vérité élémentaire que tous les développeurs professionnels connaissent. Il y a 4 ans, je n'ai pas pu mettre en ligne une version finie du concepteur parce que je n'avais pas de plan de réalisation. Si j'avais eu un plan, tout aurait été terminé depuis longtemps. La raison suivante d'arrêter le projet est la dispute stérile avec les opinions d'autres personnes sur le forum. Des débats sur les approches de la programmation ou sur la nécessité ou non de l'interface graphique en tant que telle... Malheureusement, c'était une perte de temps inutile.
Quel est donc l'aboutissement de ce projet ? La réponse à cette question est très importante car elle détermine le choix des orientations pour la suite du développement.
Et donc, tel que je le présente :
1. Contrôle logiciel des éléments d'interface.
C'est l'une des principales tâches actuelles. Actuellement, l'utilisateur peut seulement "attraper" les événements de l'interface graphique dans le fichier API, mais pas obtenir/modifier les propriétés des éléments ou les valeurs des paramètres. En pesant la complexité, je peux dire que la tâche est facile et qu'elle sera résolue avant la prochaine version. Donner à l'utilisateur un accès programmatique à un large éventail d'éléments de l'interface graphique et de propriétés des fenêtres.
2. tableaux réguliers et dynamiques .
Les tableaux réguliers ont déjà été mis en œuvre. Leur fonctionnement a été testé à plusieurs reprises. Des fonctions telles que le glisser-déposer de colonnes et de lignes (pour changer leur place dans le tableau), la réduction/expansion des lignes du tableau (ajout de l'élément T_FOLDER) ou le masquage/démasquage des colonnes ont fonctionné. L'intégration automatique des contrôles dans le tableau a fonctionné. Par exemple, les cases à cocher, les listes déroulantes, les boutons, les curseurs, les champs de saisie avec boutons et les champs de saisie simples ont tous été intégrés dans le tableau lorsque le mot-clé IS_TABLE a été ajouté à l'en-tête du groupe. Les valeurs dans les cellules peuvent être colorées en fonction de leur valeur. Les tableaux peuvent même être intégrés dans des listes arborescentes.
Cependant, cela vaut-il la peine de consacrer du temps à la réintroduction de toutes les anciennes fonctionnalités ?
C'est difficile à dire.
Je pense que la première chose à faire est de rétablir les fonctions de base des tableaux ordinaires et de s'assurer qu'elles fonctionnent bien. Le reste se fera au fur et à mesure.
Mais l'élément principal de l'interface d'un robot de trading sérieux, ce sont les tableaux dynamiques. Celles qui sont capables de passer à travers un flux infini de données provenant de la bourse. Je ne les ai jamais implémentées auparavant.
Conclusion : les tables dynamiques sont une priorité.
(Il faut commencer le développement).
3. Listes d'arbres.
Un élément de l'interface graphique assez bien réalisé et refait de nombreuses fois auparavant. Et il a fonctionné mieux à chaque fois. La dernière version est particulièrement bonne, mais elle n'est pas terminée. Si je me souviens des détails, je peux la terminer en un jour ou deux. Mais à quel point en avez-vous besoin dans une interface graphique ? Je pense que cela ne fait pas de mal, mais il ne faut pas en faire une obsession.
Conclusion : la liste des arbres n'est pas une priorité pour la suite du développement.
(Je la finirai quand j'aurai le temps.)
4. Fenêtres dynamiques.
Les mécanismes de base - redimensionnement, défilement vertical et horizontal, mise à l'échelle, adaptation de la fenêtre à l'échelle au changement de taille du graphique - fonctionnent déjà bien. Mais il y a beaucoup de petits bugs gênants. Si elles sont complètes, les fenêtres dynamiques sont idéales pour les grands tableaux dynamiques et les longues listes.
Conclusion : l'achèvement des fenêtres dynamiques est une priorité.
(Cela peut prendre deux ou trois jours de travail acharné et d'enthousiasme).
5. Minimiseurs de groupes et de tableaux.
Les éléments G_FOLDER et T_FOLDER ont déjà très bien fonctionné dans le passé. Je ne sais pas comment ils fonctionnent maintenant, car je n'ai pas eu le temps de les tester. Il est intéressant de noter que, dans le dernier développement de la fonction de phénomène d'élément, j'ai unifié la gestion de la liste d'arbres et de ces deux types d'éléments. Une fonction gérait trois éléments et ne faisait pas plus de 400 à 500 lignes (ce qui n'est pas beaucoup selon mes critères). Si je remets cette fonction en service (elle est désactivée pour l'instant), les trois éléments fonctionneront parfaitement. Voyons ce qu'il en est.
Conclusion : les éléments G_FOLDER et T_FOLDER ne sont pas prioritaires.
(Je le ferai si j'en ai l'occasion et l'envie).
Et la dernière tâche prioritaire qui me vient à l'esprit maintenant :
6. Création d'une branche de modèles de groupes d'éléments et de fenêtres écrits dans le langage de balisage.
Cela permettra aux utilisateurs de construire rapidement et facilement l'interface nécessaire pour résoudre des tâches, même sans connaissance approfondie du langage.
Si quelqu'un a des idées sur les priorités en matière de développement, qu'il les partage. J'en prendrai note.
Oui, la gestion du programme est la plus importante, une nécessité pour tous ceux qui utiliseront le moteur.
Pour moi, les tableaux dynamiques sont indispensables. J'ai besoin de l'interface principalement pour la visualisation des événements et des rapports en temps réel. Les contrôles sont le cerclage pour les gérer (filtres, etc.) Avec la mise en œuvre de ceci, je pourrais commencer à intégrer le moteur.
La deuxième priorité est une fenêtre plein écran. Mais c'est très simple - vous l'avez déjà fait dans le designer. Avec une barre des tâches. Et temporairement, je peux utiliser la plus grande fenêtre possible. Je dois choisir la taille, c'est pénible.
La troisième priorité est le graphisme. Je ne sais pas à quel point c'est difficile. Peut-être devriez-vous utiliser les outils de kanvas standard, s'ils sont suffisamment flexibles. Je n'ai jamais essayé autre chose que Fast And Furious Easy And Fast v1.
Si Dieu le veut, la motivation est suffisante. Le plus souvent, elle s'évanouit après une rencontre avec les détracteurs. "Les bonnes personnes sont majoritaires, mais les mauvaises sont mieux organisées.
La deuxième priorité est une fenêtre plein écran. Mais c'est très simple - cela se fait déjà dans le designer. Avec une barre des tâches. Et temporairement, je peux utiliser la plus grande fenêtre possible. Je dois reprendre les dimensions, ce qui est pénible.
La troisième priorité est le graphisme. Je ne sais pas si c'est très difficile. Peut-être devriez-vous utiliser les outils de kanvas standard, s'ils sont suffisamment flexibles. Je n'ai jamais essayé sauf Fast And Furious Easy And Fast v1.
Si Dieu le veut, la motivation est suffisante. Le plus souvent, elle s'évanouit après une rencontre avec les détracteurs. "Les bonnes personnes sont majoritaires, mais les mauvaises sont mieux organisées.
1. La gestion programmatique des articles sera dans la prochaine version. Provisoirement dans 7 à 10 jours.
2. Les tableaux dynamiques sont "en cours de développement". Je ne peux pas encore dire combien de temps cela prendra. Le processus peut être très rapide.... ou moins rapide. Je ne sais pas.
3. Vous avez déjà une fenêtre plein écran. Faites un essai. Dans les propriétés de la fenêtre, écrivez "DINAMIC" au lieu de "SETTINGS". Testez-le et écrivez vos impressions.(Il suffit d'aller à la version de terrain du constructeur). Vous pouvez changer la taille en tirant sur les bords de la fenêtre ou zoomer avec le bouton du haut. Il est possible de double-cliquer sur la barre supérieure (où se trouve le nom de la fenêtre), ou de saisir la fenêtre par le "chapeau" et de la faire glisser vers le haut jusqu'à ce qu'elle se mette à l'échelle d'elle-même. Les mêmes manipulations fonctionnent dans l'autre sens.
4. Imprimez le fichier API de votre fenêtre et postez-le ici. Je regarderai et je comprendrai comment les tables sont imprimées. C'est important pour l'implémentation future des connexions logicielles.
5. Je vais réfléchir sérieusement à des graphiques personnalisés. J'ai vu la mise en œuvre d'Anatoly, mais je n'ai pas essayé de reproduire cet élément.
Une nuance importante lorsque l'on travaille avec une fenêtre dynamique :
La fenêtre n'accepte pas les éléments de type V_BOX, car ils contiennent leur propre canevas. Il en résulte un chevauchement d'un canevas sur un autre. Par conséquent, cet élément doit être commenté ainsi que toutes les lignes i, IN, "V1", .
En d'autres termes, les groupes placés dans l'élément V_BOX doivent se trouver uniquement dans la fenêtre "MF". Il n'est pas nécessaire de commenter spécifiquement la ligne i, IN, "V1".
Si cela ne fonctionne pas, je vous montrerai plus en détail demain. En images.
Exemple de conversion de la fenêtre de paramétrage en fenêtre dynamique :
(cliquez sur l'image)