Mon approche. Le noyau est le moteur. - page 24
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
Bien.
Le moteur portant l'interface graphique de l'application réalise simplement la mécanique des contrôles (boutons, champs de saisie, etc...).
Appuis sur des boutons, cases à cocher, saisie de texte et autres actions de l'utilisateur, directement de sont transmises à l'application du développeur.
L'application peut transférer ses données vers des champs et des tables.
Tout se fait par le biais d'un simple fichier de connexion.
Oh, eh bien, c'est une autre affaire alors.
NET-dlls arrivent maintenant à MT. Il n'est plus difficile de faire une interface graphique en C-sharp pour MT, et avec plus de fonctionnalités. Et puisque de toute façon tous les événements sont sur des MT-ticks, alors les boutons aussi. Eh bien, l'analyse vis, imho, plus facile à DLL qu'à Peter.
En général, le moteur Peter, si quelqu'un utile, il ne sera que les vendeurs de marché, où DLL nizizzi.
Tout d'abord, vous mentez lorsque vous dites "aucune difficulté". Vous pouvez facilement créer une interface graphique en C#, mais pour la connecter à une application MQL?
Montrez-moi un exemple d'une telle connexion. C'est au moins une béquille effrayante. Vous devez tout faire à travers une DLL. Envoyer des événements, recevoir des événements...
Combien d'efforts et de temps faudra-t-il pour développer une connexion SharpGUI avec une application MT via DLL ?
Qui le fera, face à la simplicité de ma solution ? J'ai déjà une interface de connectivité. Le problème de connexion dure une demi-heure (si plusieurs fenêtres). Tout est très simple. Pas de DLL.
C'est donc une idée "en voie de disparition".
Tout d'abord, vous mentez quand vous dites que "ce n'est pas grave". Faire une interface graphique en C# est facile, mais la connecter à une application MQL?
Montrez-moi un exemple d'une telle connexion. C'est au moins une béquille effrayante. Vous devez tout faire à travers une DLL. Envoyer des événements, recevoir des événements...
Combien d'efforts et de temps faudrait-il pour développer uneinterface graphique Sharp avec une application MT via DLL ?
Qui le fera, face à la simplicité de ma solution ? J'ai déjà une interface de connexion. Le problème de connexion dure une demi-heure (si plusieurs fenêtres). Tout est très simple. Pas de DLL.
C'est donc une idée "en voie de disparition".
Tout est pareil. Aucune complication. Il n'y a aucune différence entre la fonction que vous appelez, l'application ou la DLL. Voyez-vous une complexité dans l'appel des fonctions?
Tout est pareil. Il n'y a pas de complication. La fonction que vous appelez - l'application ou la DLL - ne fait aucune différence. Voyez-vous des difficultés à appeler des fonctions?
Non. Il s'agit de la mémoire où les valeurs des paramètres doivent être synchronisées. La mémoire doit se trouver soit dans un fichier, soit dans une mémoire d'application partagée dans la DLL (ou ailleurs).
Mais ce n'est pas le point principal.
LE GÉNÉRAL :
Chaque développeur devra créer sa propre interface pour se connecter à son interface graphique sur Sharp.
Et pourquoi cela serait-il nécessaire alors que tout fonctionne déjà ?
Non. Il s'agit de la mémoire où les valeurs des paramètres doivent être synchronisées. La mémoire doit se trouver soit dans un fichier, soit dans la mémoire partagée de l'application dans la DLL (ou ailleurs).
Mais ce n'est pas le point principal.
LE GÉNÉRAL :
Chaque développeur devra créer sa propre interface pour se connecter à l'interface graphique du Sharp.
Et pourquoi cela serait-il nécessaire si tout fonctionne déjà ?
Tu es dramatique).
Tu es dramatique).
Pas du tout. Je connais la situation. J'ai fait l'interface entre une application MT et une application Sharpe, via une DLL écrite en C++. C'est une horrible douleur dans le cul. Vous devez travailler avec Visual Studio et MT en même temps. Ensuite, pour exécuter des applications en parallèle.
Mais l'essentiel est que personne n'a développé un format d'interaction des parties de l'application. Par conséquent, chacun se battra seul.
Pas une goutte. Je connais la situation. J'ai fait l'interface entre une application MT et une application Sharpe, via une DLL écrite en C++. C'est une horrible douleur dans le cul. Vous devez travailler avec Visual Studio et MT en même temps. Ensuite, pour exécuter des applications en parallèle.
Mais l'essentiel est que personne n'a développé un format d'interaction des parties de l'application. Par conséquent, chacun se débrouillera seul.
La DLL est un outil standard de Windows. L'interopérabilité des DLL a été développée et utilisée depuis l'époque du DOS. Il n'y a pas de problème du tout.
La DLL est un outil standard de Windows. L'interopérabilité avec les DLL est développée et largement utilisée depuis longtemps, depuis l'époque du DOS. Il n'y a pas de problème du tout.
L'interaction de Sharp avec la DLL a été développée. Et l'interaction d'une application ICL avec Sharp par le biais d'une DLL est un problème personnel pour le programmeur.
Il doit organiser la mémoire partagée et effectuer ses appels de fonction en fonction des drapeaux de lecture.
Par conséquent, il doit accéder sans cesse à la mémoire partagée qui se trouve dans la DLL ou dans le fichier.Après tout, il n'y a pas de rappel de Sharp vers MT via DLL.
L'interaction avec la DLL du côté de Sharp est élaborée. Et l'interaction de l'application MKL avec Sharpe via la DLL, est un problème personnel pour le programmeur.
Il doit organiser la mémoire partagée et effectuer ses appels de fonction en fonction des drapeaux de lecture.
Par conséquent, il doit accéder sans cesse à la mémoire partagée qui se trouve dans la DLL ou dans le fichier.Après tout, il n'y a pas de rappel de Sharp vers MT via DLL.
Vous n'avez pas non plus de rappel dans MT. Tout est fait par des événements prédéfinis dans MT, qui une fois pour toutes.
Vous continuerez à envoyer des événements de terminal à la DLL, et l'endroit où vous les traitez, dans MT ou dans la DLL, n'a aucune importance.
Même si l'on imagine que la vérification constante des messages de Sharp par l'application ICL n'est pas une nuisance, le développement d'un format d'interaction est une tâche très volumineuse.
Cette tâche comprend les éléments suivants :
1. Mise en place d'une organisation de la mémoire partagée.
2. Mettre en œuvre l'interaction des trois parties.
3. Test synchrone des trois côtés (Sharp, DLL, application MT).
Cela prend beaucoup de temps.
Dans mon cas, l'utilisateur reçoit le fichier et le remplit. Et la connexion fonctionne.