Mon approche. Le noyau est le moteur. - page 158
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
Attendez. Vous avez écrit :
Alors, qui a quelle armée ?
Je mettrai votre impolitesse à l'égard du "petit malin" sur le compte du fait que vous ne parlez pas bien le russe et que vous ne comprenez pas qu'il s'agit d'une attitude péjorative et dédaigneuse envers votre interlocuteur.
Pourquoi, tu as perdu ton sens de l'humour ou quoi ?
Malheureusement, oui. Une interface de rappel entre deux systèmes fondamentalement différents n'est pas possible.
En fait, la question était presque rhétorique).
IMHO, avec la compatibilité NET ajoutée, il est nécessaire d'ajouter des callbacks au terminal. Au moins un) Au moins, pour pousser l'événement dans la file d'attente des terminaux.
Si c'est par le biais d'une minuterie, comment allez-vous travailler dans le testeur ? Je croyais que tu avais dit que tu faisais du code multiplateforme.
Artyom, quelles questions ? Si la minuterie ne fonctionne pas, elle est émulée à partir d'autres sources...
c'est même dans le "robot de combat" toujours ainsi, parce que l'EventSetTimer:-)
ps/ il y a quelque chose de contagieux dans les thèmes militaristes... postes de commandement, robots de combat... "Galacteco Danger"
En fait, la question était presque rhétorique).
À mon avis, avec l'ajout de la compatibilité NET, il y a un fort besoin d'ajouter des rappels au terminal. Au moins un) Au moins, en poussant l'événement dans la file d'attente du terminal.
Je ne suis pas en mesure d'attraper les événements dans MT5, Spy++ ne peut pas voir les événements du graphique pour une raison quelconque. Il semble que les classes auto-écrites et les modèles d'événements sont utilisés au lieu des événements standard de Windows.
J'utilise également OnTimer, c'est pourquoi j'essaie de recevoir un minimum de paquets de données dans la requête, bien qu'à la vitesse actuelle du PC, je devienne peut-être gourmand))).
Si la minuterie, comment travaillez-vous dans le testeur ? Je pensais que vous aviez dit que vous faisiez du code multi-plateforme.
Quand j'ai essayé d'utiliser МТ5, c'était un vrai plaisir d'écrire sous C# - j'appelle .dll, je démarre immédiatement un formulaire et je mets tous les graphiques dans un thread séparé ( Thread ) et c'est tout, après cela je travaille juste avec l'échange de données entre C# et МТ5 et le formulaire graphique avec des boutons fonctionne comme une application widow habituelle - la demande de МТ5 reçoit seulement le statut des éléments cliqués précédemment et rien ne freine ou ne freinera ;).
Artyom, c'est quoi ces questions ? Si la minuterie ne fonctionne pas, c'est qu'elle est émulée à partir d'autres sources...
c'est même toujours le cas dans le "robot de combat", car EventSetTimer :-)
ps/ il y a quelque chose de contagieux dans les thèmes militaristes... postes de commandement, robots de combat... "Galacteco Danger"
Eh bien... Je voulais demander à Vassili comment il s'y prendrait. Afin de le comparer avec ce que j'ai fait moi-même il y a longtemps (non sans les conseils de Vasil, bien sûr)
Je n'ai pas réussi à capturer les événements dans MT5, pour une raison quelconque, Spy++ ne peut pas voir les événements du graphique, il semble que des classes et des modèles d'événements auto-écrits soient utilisés plutôt que les modèles standard de Widows, dans MT4 je peux envoyer un événement Widows sans aucun problème.
J'utilise également OnTimer, c'est pourquoi j'essaie de recevoir un paquet de données minimum dans la requête, bien qu'à la vitesse actuelle du PC, je devienne peut-être gourmand))).
Quand j'ai essayé d'utiliser OnTimer dans MT5, le timer dans le testeur est généré sans problèmes et c'est un vrai plaisir d'écrire sous C# - j'appelle .dll, je démarre immédiatement le formulaire et je mets tous les graphiques dans un thread séparé ( Thread ), après cela vous travaillez juste avec l'échange de données entre C# et MT5 et le formulaire graphique avec les boutons fonctionne par lui-même comme une application widow habituelle - dans la requête MT5, seul le statut des éléments cliqués précédemment est envoyé, rien n'est lag et ne sera pas lag ;)
Je l'ai fait en cinq via un minuteur dans le testeur. Même son utilisation simple (il s'agit d'un multitimer à millisecondes) entraîne un sérieux ralentissement du testeur. Il suffit donc de refuser le timer dans le visualiseur - c'est la même chose pour travailler sur les ticks. Création de deux modèles - par timer et par événements de drapeaux via OnTick(). Par minuterie en temps réel, par ticks - dans le visualiseur.
Lies - trois modèles - également via OnChartEvent() - uniquement en temps réel là aussi.
Je n'ai pas réussi à capturer les événements dans MT5, pour une raison quelconque, Spy++ ne peut pas voir les événements du graphique, il semble que des classes et des modèles d'événements auto-écrits soient utilisés plutôt que les modèles standard de Widows, dans MT4 je peux envoyer un événement Widows sans aucun problème.
J'utilise également OnTimer, c'est pourquoi j'essaie de recevoir un paquet de données minimum dans la requête, bien qu'à la vitesse actuelle du PC, je devienne peut-être gourmand))).
Lorsque j'ai essayé d'utiliser OnTimer dans MT5, le timer dans le testeur est généré sans problèmes, et c'est un plaisir d'écrire du code sous C# - j'appelle .dll, je démarre immédiatement le formulaire et dans un thread séparé ( Thread ) tous les graphiques et c'est tout, maintenant je travaille juste avec l'échange de données entre C# et MT5, et le formulaire graphique avec les boutons fonctionne par lui-même comme une application Windows habituelle - dans la demande MT5 seul le statut des éléments cliqués précédemment est envoyé, rien n'est lag et ne sera pas lag ;)
Si vous faites aussi le modèle au niveau MQL et d'autres choses à Sharpey, ce sera génial. Alors la logique est séparée, la vue est séparée. Le front-end s'occupe de la conception et de la convivialité et ne s'occupe pas du back-end commercial. Modifier la configuration des boutons d'un formulaire ou diviser un formulaire en deux ou trois ne devrait pas affecter les algorithmes du conseiller expert.
Peter, si vous le voulez bien, je vais préparer un article sur la façon dont une application graphique peut être créée assez facilement dans MQL, en utilisant la nouvelle fonctionnalité d'intégration avec les bibliothèques .Net. Le titre de l'article sera "Créer des formulaires personnalisés dans VisualStudio pour les experts en négociation basés sur .Net Framework et C#".
Votre approche et vos idées m'ont enthousiasmé. Je me suis demandé s'il était possible de créer rapidement et facilement un formulaire graphique pour mon conseiller expert, en utilisant uniquement des compétences de base en programmation. J'ai fait une expérience, et il s'est avéré que c'est possible ! J'ai reçu un formulaire comme celui-ci :
L'idée était que l'utilisateur dessine le formulaire requis dans l'éditeur VisualStudio et que tout le travail nécessaire à l'intégration de cette fenêtre avec le code MQL soit effectué en coulisses, en mode automatique. Pour ce faire, j'ai dû écrire un contrôleur C# - une sorte d'analogue de votre noyau, cependant, cela ne prend qu'environ 200 lignes de code.
Vous pouvez lire comment tout cela fonctionne dans l'article que j'ai commencé.
C'est ça, Vasiliy, tu as couvert ton noyau avec un chaudron.
C'est ça, Vassily, tu t'es couvert la tête avec un chaudron.
On s'attend généralement à ce que ça se termine comme ça, mais il n'y a pas encore d'article spécifique...
bien qu'il y ait 99% de chances qu'un tel article sorte avant le noyau-moteur. Peter doit s'en tenir au pourcentage restant.
Je l'ai fait dans les cinq via la minuterie du testeur. Le simple fait de l'utiliser (et c'est un multitimer à millisecondes) a provoqué un sérieux ralentissement du testeur. Il suffit donc de refuser le timer dans le visualiseur - c'est la même chose pour travailler sur les ticks. Création de deux modèles - par timer et par événements de drapeaux via OnTick(). Par minuterie en temps réel, par tics - dans le moteur de rendu.
ZS. Je mens - trois modèles - aussi par OnChartEvent() - là aussi, seulement en temps réel.
Je n'ai pas encore décidé du design, j'ai vérifié qu'il fonctionne dans le testeur sans aucun problème, merci à@fxsaber pour son aide avec le code #define - j'ajoute automatiquement les handlers OnTick() et OnTimer() quand je branche l'injecteur... afin que je puisse faire les appels nécessaires dans n'importe quelle section du conseiller expert.
Je ne sais même pas où se situe le décalage... J'utilise assez souvent le timer - 400 ms, mais l'appel ne provient que du .dll 2 tableaux int 10-ele-v et 2 int (combien de boutons et combien de cases à cocher, une telle dimension de tableaux), il ne peut tout simplement pas physiquement ralentir, parce que même écrire dans le tableau si le bouton a été cliqué, et dans le nombre int j'envoie un bouton, le tableau n'est pas nécessaire en principe, comme une précaution si l'utilisateur a une dépression nerveuse et il plus rapide que 0,5 secondes va battre le bouton ))))
Je suppose que nous avons des tâches différentes - quand il s'agit de la construction de TS, vous n'avez pas besoin de graphiques, et quand il s'agit du débogage et de la visualisation de TS, vous n'avez pas besoin de la vitesse du testeur ;)
Si vous faites également un modèle au niveau MQL, et le reste en Sharpay, ce serait formidable. Alors la logique est séparée, la vue est séparée. Le front-end s'occupe de la conception et de la convivialité et ne s'implique pas dans le back-end commercial. La modification de la configuration des boutons d'un formulaire ou la division d'un formulaire en deux ou trois ne devrait en aucun cas affecter les algorithmes du conseiller expert.
Je vais le garder comme un bon poste ! Et l'écrire dans la description, si je suis mûr pour les commentaires du public.