Mon approche. Le noyau est le moteur. - page 28
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
Au fait, la bibliothèque d'Anatoly est aussi une blague. Combien d'articles sur le sujet ? Environ 50 ans ? Partout où vous allez dans les commentaires - "Oh, pas encore, je dois l'améliorer". Pour commencer à utiliser sa bibliothèque, vous devez lire ces 50 articles ? Quel est l'essentiel et la signification ?
J'ai essayé de connecter la bibliothèque mentionnée, mon avis est ambigu, oui c'est pratique, oui c'est beau, mais je n'étais pas engagé dans MQL quand la bibliothèque a été créée, et avec les builds ultérieurs de MT, la bibliothèque est devenue "conditionnellement opérationnelle", certains exemples des articles ne compilent pas ou fonctionnent avec des bugs, et pour comprendre les tonnes de code, hélas, il est plus facile d'utiliser la livraison standard de MT
Les constructeurs d'interface graphique modernes (ceux qui "étalent les boutons sur les formulaires") sont une chose assez technologique et y attacher des éléments MQL ne semble pas fantastique.
Presque tous ont dans la forme intermédiaire (fichier de projet, etc.) un XML décrivant la position et les relations entre les éléments.
La génération de code pour la plateforme cible est en fait une transformation XSLT qui peut être réalisée par quiconque se prend pour un développeur web :-)
Prenons par exemple EasyAndFast (https://www.mql5.com/ru/code/19703), car il est basé sur l'objet et possède tous les composants nécessaires. (et est ouvert et documenté, contrairement à ce qui se passe dans ce fil),
et écrire simplement un traducteur.
Il n'y a pas de constructeur gui-mql, non pas parce que c'est méga compliqué, mais parce que ce n'est tout simplement pas populaire.
Oui, je les cherche - je suis intéressé, au moins pour mettre Peter dans le pétrin ! ))))
Je n'ai ni le temps ni l'envie de m'occuper de tous les détails - pourquoi ne pas simplement utiliser Crossplatform GUI builder ?
J'ai essayé de connecter la bibliothèque mentionnée ci-dessus, mon avis est ambigu, oui c'est pratique, oui c'est beau, mais je n'étais pas engagé dans MQL quand cette bibliothèque a été créée, et avec les builds ultérieurs de MT, la bibliothèque est devenue "conditionnellement opérationnelle", certains exemples des articles ne compilent pas ou fonctionnent avec des bugs, et pour comprendre des tonnes de code, hélas, il est plus facile d'utiliser le paquet MT par défaut
Oui, je le cherche - au moins pour mettre Peter dans le pétrin ! ))))
Je n'ai ni le temps ni l'envie de me pencher sur tout cela !
Jetez un coup d'œil à QT Designer.
Peter, où est-il dit que votre interface graphique n'est pas constituée d'objets graphiques, mais qu'elle est dessinée sur un canevas ? Ne soyons pas sournois, ça a l'air terrible.
...
En tant qu'artiste, je ne pouvais pas passer outre ces mots.
Bien sûr, loin d'être IDEAL, mais "affreux" ???
Oui, j'en cherche un - j'aimerais au moins mettre le nez de Peter dans cette affaire ! ))))
Mais sérieusement, j'aimerais essayer un constructeur d'interface graphique multiplateforme, peut-être quelque chose à montrer, que je puisse regarder?
Pas besoin d'essuyer)). Et il n'y a pas besoin de chercher.
DLL à C-sharp. L'environnement VS possède déjà un constructeur. Le langage est presque similaire à celui de MQL. Si ce n'est pas pour le marché, mais pour vous-même, l'option la plus simple et la plus évidente avec un look et une ambiance modernes.
Et ce que Peter propose est l'interface graphique de type DOS de la série Turbo Vision de Borland au début des années 90.
Et ce que Peter propose est une interface graphique de type DOS provenant de la série Turbo Vision de Borland au début des années 90.
C'est une très bonne interface graphique. Je suis peut-être trop vieux, mais je trouve que c'est plutôt bien.
La question est de savoir qui pourrait être intéressé à l'utiliser. Combien y en a-t-il ?
Faire votre propre interface graphique n'est pas le problème.
Le problème est de trouver un usage utile pour ce produit qui soit nécessaire à un GRAND nombre d'utilisateurs. Jusqu'à présent, c'est ce qui pose problème à tout le monde. S'il y a une tâche normale, il y aura une interface graphique, et plus d'une...
Petr, quelle est la réponse à la question POURQUOI les utilisateurs ont-ils besoin de votre produit ? Je comprends que vous soyez fasciné par le processus, je l'ai vécu. Mais, pourquoi les utilisateurs en ont-ils besoin ? Qui est le public cible ?C'est une très bonne interface graphique. Peut-être que je suis trop vieux, mais je pense que c'est assez bon.
La question est de savoir qui serait intéressé à l'utiliser. Combien d'entre eux sont ici ?
Bon ou mauvais - tout dépend des tâches spécifiques. Il y a quelques années, j'ai conçu un terminal GUI sur des feuilles Excel - avec des boutons, des champs, des tableaux, des graphiques en temps réel et d'autres attributs. J'en avais besoin spécifiquement pour le trading manuel. Il n'y a eu aucun problème avec la construction et l'interface.
L'interface graphique de Peter est présentée comme une solution au problème et une simplification de la construction. Il l'a conçu et réalisé, et c'est bien, bien sûr, mais il n'y a pas de problème ici depuis longtemps, et il n'y a pas grand-chose à simplifier.
Mm-hmm - magnifique. Il y a également une incohérence (dans le style) avec certaines des autres captures d'écran, ce qui est très discutable.
Voici un exemple de mon interface de connexion :
Tout est déjà réglé ici.
J'ai jeté un coup d'oeil. C'est un désordre. Le fichier est presque entièrement occupé par la fonction On_Gui_Event, qui compte 600 lignes. En voici un fragment (l'orthographe et la ponctuation sont préservées) :
C'est n'importe quoi. Le code ne se compile naturellement pas. Aucune des constantes de cas n'est définie dans le fichier. L'interrupteur est à l'intérieur du boîtier. Les retraits sont faits de telle manière que l'on pourrait croire que l'on veut déconcerter un pauvre utilisateur. Il y a un tas de code tout simplement inefficace comme if(selected_option == "L_ITEM 1"){}. En bref, c'est la catastrophe.
J'ai jeté un coup d'oeil. C'est un désordre. Le fichier est presque entièrement occupé par la fonction On_Gui_Event, qui compte 600 lignes. En voici un fragment (l'orthographe et la ponctuation sont préservées) :
C'est n'importe quoi. Le code ne se compile naturellement pas. Aucune des constantes de cas n'est définie dans le fichier. L'interrupteur est à l'intérieur du boîtier. Les retraits sont faits de telle manière que l'on pourrait croire que l'on veut déconcerter un pauvre utilisateur. Beaucoup de code inefficace du type if(selected_option == "L_ITEM 1"){} En bref, c'est la catastrophe.
Vasily, tu m'as beaucoup fait rire. )) Pourquoi devriez-vous essayer de compiler tout ce qui vous tombe sous la main) ?
Voici un exemple de fichier de connexion GUI. Demandez à Oleg Papkov comment cela fonctionne. Quel genre de "code inefficace" ? Un code normal qui est fait pour être aussi clair que possible.