Mon approche. Le noyau est le moteur. - page 60
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
...
Mais si vous savez comment fonctionne le modèle d'événement dans Windows et si vous avez l'expérience de travailler avec des compilateurs avec des concepteurs de formulaires, alors tout est identique partout.
ZS : c'est la troisième fois que je vois Sharp, mais j'ai eu une grande expérience avec Delphi, je ne vois pas du tout la différence, tout fonctionne de la même façon, ce qui ne fonctionne pas est googlé dès la première fois.
Je ne me souviens pas comment fonctionne le modèle d'événement de Windows. Et j'ai une longue expérience des compilateurs et des concepteurs.
Je dois connecter un formulaire créé à une application MT et résoudre le problème. Tu as dit que c'était facile.
En ne le montrant pas, mais en décrivant très clairement ses principes. C'est ce à quoi ils s'opposent, c'est ce qu'ils disent : "la route est mauvaise".
En outre, elle est "mauvaise" non pas pour l'auteur, mais pour ceux qui s'y opposent. Ils ont un cerveau semblable à celui d'une poule et ne peuvent pas se souvenir de l'endroit et des objets qu'ils ont créés, de l'endroit et des personnes qui y font référence, de la signification de chaque cellule du tableau, de l'endroit où ils peuvent changer et de celui où ils ne peuvent pas... Il est compréhensible que les opposants soient outrés. Au lieu d'entraîner leur mémoire, afin qu'ils puissent facilement mémoriser quelques milliers d'objets et de références dans le programme, les gens stupides découpent leurs propres droits d'accès, définissent quelques distinctions, quelques interfaces, quelques fonctions polymorphes... Ils se torturent, comme sous le régime tsariste, hein...
Oubliez les bêtises sur la fraîcheur de la mémoire. On observe parfois que le fil de ce dialogue de forum n'est pas suivi jusqu'à la profondeur de deux pages. De plus, il y a trop de déni pour que la mémoire fonctionne si bien, comme on essaie de nous le faire croire.
Aidez-moi à résoudre un problème.
Le formulaire Windows est là. Il démarre et fonctionne. Les boutons et les cases à cocher sont cliquables.
Il faut maintenant une DLL pour se connecter à MT5. Qui sait comment faire ?
Aidez-moi à résoudre un problème.
2. Hier, Igor a montré un exemple. Il montre comment dans l'Expert Advisor vous pouvez appeler la méthode d'une classe, contenue dans la dll importée. Autrement dit, vous devez écrire une fonction (méthode) en c# qui modifie l'état de la case à cocher. Comment modifier la propriété d'une case à cocher, je ne me souviens pas du nom de la méthode, il est facile de naviguer par la liste déroulante, vous devez entrer le nom de la case à cocher, appuyer sur un point...
1. Je ne sais pas. Probablement pas. Vous devez appeler une fonction dll à partir du timer et regarder l'état des cases à cocher. Quant aux événements tels que les pressions sur les boutons, nous pourrions probablement créer un tableau et y stocker les événements. Mais ce n'est pas difficile, compte tenu de l'avantage de travailler avec des commandes visuelles.
Installé C#. Ouverture d'un projet. J'ai créé un formulaire et j'y ai ajouté deux boutons et trois cases à cocher.
Voici le code dans l'éditeur :
Question : Pourquoi y a-t-il une fonction pour un bouton et où sont les fonctions pour le deuxième bouton et les cases à cocher ?
J'ai trouvé ce code :
Comment l'utiliser pour l'interface avec MT5 ?
Vous devez démontrer que le deuxième bouton est nécessaire - faites un double-clic sur celui-ci, puis le code s'ouvrira et la fonction sera ajoutée. Le projet compilera avec une erreur si le bouton est ensuite retiré du formulaire, le code doit être supprimé manuellement d'un fichier, mais pas celui que vous avez écrit.
2. Hier, Igor a montré un exemple. L'exemple montre comment un Expert Advisor peut appeler une méthode d'une classe dans la dll importée. Autrement dit, vous devez écrire une fonction (méthode) en c# qui modifie l'état de la case à cocher. Comment modifier la propriété d'une case à cocher, je ne me souviens pas du nom de la méthode, il est facile de naviguer par la liste déroulante, vous devez entrer le nom de la case à cocher, appuyer sur un point...
1. Je ne sais pas. Probablement pas. Vous devez appeler une fonction dll à partir de la minuterie et surveiller l'état des cases à cocher. Quant aux événements tels que les pressions sur les boutons, nous pourrions probablement créer un tableau et y stocker les événements. Mais ce n'est pas difficile, compte tenu de l'avantage de la manipulation visuelle des contrôles.
Ok.
Donc, nous devons :
Et s'il y a des centaines d'éléments ?
Comment organiser la mémoire partagée ?
Que faire s'il est nécessaire de modifier non seulement l'état enfoncé/relâché des éléments d'un formulaire, mais aussi leur couleur (par exemple, pour les boutons) ?
Que faire si vous devez modifier le texte des champs de saisie d'un formulaire de manière programmatique à partir de MT5 ?
En ce qui concerne les événements tels que les pressions sur les boutons, il est probablement préférable de créer un tableau et d'y stocker les événements. Mais ce n'est pas difficile, compte tenu de l'avantage du travail visuel avec des contrôles.
J'avais l'habitude de le faire d'une manière plus simple :
1. l'utilisateur a appuyé sur le bouton du formulaire - le gestionnaire d'événements OnClick() a été cliqué et Button1.Disable a été créé ;
2. ensuite, c'est à MT5 d'organiser l'échange, j'aime que les clics de bouton soient interrogés dans OnTick() - vous ne ferez rien tant qu'il n'y a pas de tick ; vous pouvez définir une valeur neutre d'environ 300 ms dans le timer - ni l'utilisateur ne remarquera de frisottis, ni MT5 ne ralentira.
Mais le point de mon exemple est que la visualisation du panneau dans MT5 est maintenant possible en 2 clics, les gestionnaires de boutons fonctionnent dans une .dll, et une partie du script de l'interface peut être transférée dans un formulaire, les mêmes tables, la manipulation des données.... tout
Et surtout, vous gagnez du temps sur le rendu, avec le Forms Designer tout est fait en quelques heures ;)
Rehtag Konow:
Créer une mémoire partagée dans la DLL. Ainsi, lors de l'accès à partir de MT5, le drapeau de changement d'état des boutons et des cases à cocher sera activé. L'application accède à la mémoire partagée, lit les drapeaux et sait que l'état de tel ou tel élément du formulaire doit être modifié.
Écriture d'une référence cyclique à la DLL à partir du timer dans MT5 pour lire les drapeaux des appels de fonction ou entrer du texte dans les champs.
Et s'il y a des centaines d'éléments ?
Comment organiser la mémoire partagée ?
Vous allez encore dans la mauvaise direction, sortez des années 2000 hirsutes ! .... bien que d'une certaine manière je pense que les années 2000 ne sont pas la limite pour vous ))))
Sans vouloir vous offenser, j'espère ?
J'avais l'habitude de le faire d'une manière plus simple :
1. l'utilisateur a appuyé sur le bouton du formulaire - il est immédiatement entré dans le gestionnaire OnClick(), ce qui a rendu Button1.Disable ;
2. ensuite, c'est à MT5 d'organiser l'échange ; j'aime que les clics de bouton soient interrogés dans OnTick() - de toute façon, tant qu'un tick n'est pas atteint, vous pouvez fixer une valeur neutre d'environ 300 ms dans le timer - ni l'utilisateur ne remarquera un friselis, ni MT5 ne ralentira
Mais le point de mon exemple est que la visualisation du panneau dans MT5 est maintenant possible en 2 clics, les gestionnaires de boutons fonctionnent dans une .dll, et une partie du script de l'interface peut être transférée dans un formulaire, les mêmes tables, la manipulation des données.... tout
le meilleur est le gain de temps sur le rendu, avec le Forms Designer tout est fait en quelques heures ;)
Vous allez encore dans la mauvaise direction, sortez des années 2000 hirsutes ! .... cependant je pense que les années 2000 ne sont pas la limite pour vous ))))
Sans rancune, j'espère ?
Sans vouloir vous offenser, c'est dommage qu'il ne soit pas à la hauteur.
Vous prenez l'exemple le plus proche et vous extrapolez à partir de celui-ci, en croyant que la complexité n'augmentera pas. C'est une erreur.
Même l'exemple le plus simple que vous avez donné est faux. Car en plus du formulaire créé, vous devez également créer une DLL. Et ensuite vous devez créer une mémoire TOTALE à l'intérieur de la DLL.
Au fur et à mesure que le nombre d'éléments de formulaire augmente et que la fonctionnalité du programme sur MT5 devient plus complexe, cette interaction devient TRÈS chargée et compliquée.
J'ai testé tout cela en pratique.
OK.
Il est donc nécessaire de :
Et s'il y a des centaines d'éléments ?
Comment organiser la mémoire partagée ?
Que faire s'il est nécessaire de modifier non seulement l'état enfoncé/relâché des éléments d'un formulaire, mais aussi leur couleur (par exemple, pour les boutons) ?
Que faire si nous avons besoin de changer le texte des champs de saisie d'un formulaire de manière programmatique à partir de МТ5 ?
Si les événements sont traités correctement, le nombre de contrôles n'est pas un problème. Dans dll, nous pouvons créer un tableau ou deux tableaux, l'un pour le nom de l'objet et le second pour le type d'événement. En dll, écrivez une fonction avec deux paramètres, ainsi que le nom et le type de l'événement. À partir de chaque gestionnaire d'événements souhaité, appelez cette fonction, de sorte que les événements soient placés dans des tableaux. Une autre méthode - pour suivre les événements de EA timer, aussi pratique ou comme il s'avère - les mêmes tableaux par référence ou autre et aussi une variable - avec le nombre d'événements dans le tableau. Après l'appel de cette méthode, les tableaux sont effacés.
Ou peut-être est-il plus facile de créer un tableau avec un seul tableau ; il existe un objet événement en c#, je peux donc les transformer en un tableau. De même, il est peut-être possible de faire en sorte que chaque gestionnaire d'événement n'appelle pas une fonction à lui seul. Mais cela n'a pas d'importance ; de toute façon, c'est une bagatelle par rapport aux capacités de l'interface et à toute la puissance de c#.