
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
Absolument. Il m'a fallu des mois pour créer mon propre framework GUI avec MQL, sans compter l'expérience que j'avais déjà dans le passé en créant des bibliothèques comme celles-ci. La partie la plus difficile n'est pas les événements, c'est plus l'architecture et la quasi impossibilité de déboguer le code, à cause de toutes les imbrications et récursions mais aussi à cause des états de la souris qui deviennent déjà invalides quand le débogage commence.
A propos, j'ai proposé une collaboration à MQ avec ces librairies il y a des mois et malheureusement je n'ai même pas eu de réponse. Mais le fait est que la bibliothèque de contrôle standard est juste un bel essai, mais aussi un mauvais essai par rapport à ce qui est réellement possible. On peut faire beaucoup mieux. Peut-être que je devrais proposer la bibliothèque sur le marché ici, mais j'ai peur du travail que cela représente d'écrire toute la documentation pour elle.
Ce n'est pas du tout une question. La POO est basée sur les principes de la nature. La terre ne vous nourrit pas, elle fournit juste les ressources et c'est à vous de décider si, quand et où vous en avez besoin.
Vous voulez dire que lors de la création d'un cadre, il suffit de s'occuper de fournir les ressources ? J'ai compris cela, mais j'ai du mal à le mettre en pratique car ma tendance est trop forte.
Par exemple, si je crée un cadre et que je crée le bouton et le bouton radio, qui est une sorte de conteneur de bouton, lorsque je crée le bouton radio, ma tendance est de penser à l'objet dépendant, le bouton dans ce cas, et à la façon dont je communique avec lui. C'est une habitude de programmation procédurale, je me demande si vous avez fait le changement dans votre passé de la programmation procédurale à l'OO et si vous pouvez m'indiquer une vue claire de ce sur quoi je dois me concentrer dans ce cas. Parce que j'ai tendance à me concentrer davantage sur le bouton (objet dépendant) que sur le bouton radio.
Je ne suis pas sûr d'avoir été clair, c'est juste une question sur les points importants sur lesquels il faut se concentrer lors de la création d'un niveau dans un framework.
Pouvez-vous dire ce que vous entendez par là ? J'ai l'impression générale de ce que vous dites, mais ce n'est pas très clair.
Vous voulez dire que lors de la création d'un cadre, il suffit de fournir les ressources ? J'ai compris cela, mais j'ai du mal à le mettre en pratique car ma tendance est trop forte.
Par exemple, si je crée un cadre et que je crée le bouton et le bouton radio, qui est une sorte de conteneur de bouton, lorsque je crée le bouton radio, j'ai tendance à penser à l'objet dépendant, le bouton dans ce cas, et à la façon dont je communique avec lui. C'est une habitude de programmation procédurale. Je me demande si vous n'avez pas fait le passage de la programmation procédurale à la programmation ouverte et si vous ne pouvez pas m'indiquer une vue claire de ce sur quoi je dois me concentrer dans ce cas. Parce que j'ai tendance à me concentrer davantage sur le bouton (objet dépendant) que sur le bouton radio.
Je ne suis pas sûr d'avoir été clair, c'est juste une question sur les points importants sur lesquels il faut se concentrer lors de la création d'un niveau dans un framework.
Peut-être que je n'ai pas compris, mais je voudrais vous donner mon opinion.
Je pense que vous êtes trop sur la "théorie", et que vous attendez la lumière de quelqu'un d'autre. Il n'y a pas de solution parfaite, il y a des solutions et vous devez les trouver à partir de votre expérience et de vos besoins concrets.
Ce sujet est parti d'un cas pratique, et il est devenu une discussion obscure sur la POO. Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.
C'est juste une suggestion, car je ne vois vraiment pas comment on pourrait vous aider beaucoup mieux.
Peut-être que je n'ai pas compris, mais je voudrais vous donner mon opinion.
Je pense que vous êtes trop sur la "théorie", et que vous attendez la lumière de quelqu'un d'autre. Il n'y a pas de solution parfaite, il y a des solutions et vous devez les trouver à partir de votre expérience et de vos besoins concrets.
Ce sujet est parti d'un cas pratique, et il est devenu une discussion obscure sur la POO. Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.
C'est juste une suggestion, car je ne vois vraiment pas comment on pourrait vous aider beaucoup mieux.
Alain, j'ai construit une interface et j'ai lu les articles.
Ce n'est peut-être pas l'endroit pour discuter d'OO, tu as peut-être raison.
J'ai commencé à en discuter parce que Doerk a présenté le sujet comme réponse au sujet débutant et a parlé de l'approche OO correcte.
Le sujet beginner lui-même était intéressé par la présentation OO de Doerk, et je pense qu'il est naturel d'en discuter ici.
Vous avez peut-être raison de dire que c'est trop théorique, mais je pense quand même qu'une approche OO correcte ne peut pas se passer d'une certaine théorie et qu'à la fin, elle devient pratique.
Ma difficulté est la pensée correcte OO, je me demandais juste si par hasard Doerk pourrait connaître de son expérience la difficulté mentale que j'ai présentée.
Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.
Je viens de le télécharger pour voir ce qu'il fait. Et la première impression montre, qu'ils ont fait les mêmes mauvaises erreurs qu'avec la bibliothèque de contrôle standard. Déjà le tout premier exemple avec une seule fenêtre de dialogue fait passer l'utilisation du CPU de 10% (sans) à 50-65% (chargé). C'est déjà la meilleure preuve que les auteurs n'ont pas l'expérience nécessaire pour développer une telle bibliothèque et que cela ne peut pas être - une - façon de faire les choses correctement.
De toute façon, je ne comprends pas pourquoi MQ ne fournit pas un cadre professionnel d'interface graphique au lieu d'expliquer comment c'est (pas) fait. La plupart des programmeurs MQL veulent sûrement développer des EAs et des Indicateurs, mais ne veulent pas s'embêter avec ce genre de choses.
De plus, le panel de leur exemple est mort dans le testeur de stratégie, et c'est là que tous ces trucs GUI deviennent absurdes de toute façon. Ce n'est pas une critique contre vous ou contre ce que vous avez écrit, je sais moi-même qu'il n'y a tout simplement pas de meilleur matériel public disponible pour MQL ici.
Alain, j'ai construit une interface et j'ai lu les articles.
Peut-être que ce n'est pas l'endroit pour discuter de la POO, tu as peut-être raison.
J'ai commencé à en discuter parce que Doerk a présenté le sujet comme réponse au sujet débutant et a parlé de l'approche OO correcte.
Le sujet beginner lui-même était intéressé par la présentation OO de Doerk, et je pense qu'il est naturel d'en discuter ici.
Bien que vous ayez peut-être raison de dire que c'est trop théorique, je pense néanmoins qu'une approche OO correcte ne peut se faire sans impliquer une certaine théorie et qu'à la fin, elle devient pratique.
Ma difficulté est la pensée correcte OO, je me demandais juste si par hasard Doerk pourrait connaître de son expérience la difficulté mentale que j'ai présentée.
Il n'y a aucun problème à discuter de la POO ici.
Je ne suis pas d'accord avec votre "OO ne peut pas sans impliquer une certaine théorie", mais cela n'a pas d'importance.
Il n'y a aucun problème à discuter de la POO ici.
Je ne suis pas d'accord avec votre "OO ne peut pas sans impliquer une théorie", mais cela n'a pas d'importance.
Je viens de le télécharger pour voir ce qu'il fait. Et la première impression montre qu'ils ont fait les mêmes mauvaises erreurs qu'avec la bibliothèque de contrôle standard. Déjà le tout premier exemple avec une seule fenêtre de dialogue fait passer l'utilisation du CPU de 10% (sans) à 50-65% (chargé). C'est déjà la meilleure preuve que les auteurs n'ont pas l'expérience nécessaire pour développer une telle bibliothèque et que cela ne peut pas être - une - façon de faire les choses correctement.
De toute façon, je ne comprends pas pourquoi MQ ne fournit pas un cadre professionnel d'interface graphique au lieu d'expliquer comment c'est (pas) fait. La plupart des programmeurs MQL veulent sûrement développer des EAs et des Indicateurs, mais ne veulent pas s'embêter avec ce genre de choses.
De plus, le panel de leur exemple est mort dans le testeur de stratégie, et c'est là que tous ces trucs GUI deviennent absurdes de toute façon. Ce n'est pas une critique contre vous ou contre ce que vous avez écrit, je sais moi-même qu'il n'y a tout simplement pas de meilleur matériel public disponible pour MQL ici.
Doerk, vous avez très probablement raison, mais ce n'est pas ce que je veux dire.
Vous devriez écrire un exemple concret expliquant pourquoi ce problème de CPU se produit, expliquer à Anatoli (auteur des articles) quel est le problème. Je suis désolé de dire que, jusqu'à présent, tout ce que vous avez dit est presque inutile, même si vous avez 100% raison. C'est juste trop général et théorique. Sans vouloir vous offenser.
Le problème est que cette question est beaucoup trop complexe pour donner des instructions exactes. C'est pourquoi j'essaie de donner quelques idées et des pistes à ceux qui sont intéressés. Malheureusement, je n'ai pas le temps d'écrire un article ni de publier une bibliothèque entièrement documentée. Je suis désolé.