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
Vous pouvez faire quelque chose comme ça : dans un dll, un tableau ou deux tableaux, l'un pour le nom de l'objet et l'autre pour le type d'événement.
ici !
Je ne l'ai pas encore vérifié, mais si les développeurs ont un support avancé pour C#.Net, alors peut-être que l'échange de types de données complexes entre MT5 et .dll fonctionne , c'est-à-dire des structures.
Si l'échange de structures fonctionne, la tâche devient encore plus simple et primitive.
nous remplissons la structure avec OrderProfit,OrderTicket,OrderStoploss.... sur le tick ... et envoyer cette structure à une .dll et recevoir une structure de réponse de l'utilisateur ... Ensuite, le formulaire fait pivoter l'information visuelle sur elle-même, le terminal lui-même.
Et ensuite créer une mémoire TOTALE à l'intérieur de la .dll.
Avec l'augmentation du nombre d'éléments de formulaire et la complexité croissante du programme MT5, cette interaction devient TRÈS chargée et complexe.
Hmmm, qu'est-ce qui est compliqué dans tout ça ? Vous séparez la visualisation = .dll, séparément le travail de MT
difficile à expliquer, avez-vous une idée de la vitesse d'échange des données dans la mémoire ? - nous ne parlons pas d'une centaine de milliers d'octets par seconde, pas même des millions, plusieurs milliards d' octets par seconde, et vous parlez de la complexité de l'échange )))))
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 s'il est nécessaire de modifier le texte des champs de saisie d'un formulaire de manière programmatique depuis МТ5 ?
1. Quel est le problème ? Il s'agit de sélectionner le type de projet lorsque vous le créez.
2. Comme on le voit dans l'exemple montré par Igor, la connexion se fait en une ligne, il n'est même pas nécessaire de décrire l'importation.
3. une méthode est écrite une fois, sauvegardée dans un fichier, et ensuite elle est utilisée dans tous les projets sans aucune modification.
4. Probablement, c'est nécessaire, mais ils sont simples. Tous ne seront probablement pas nécessaires, l'interaction entre les éléments de contrôle en c# sera différente, et il peut être nécessaire de placer un événement, et il y aura 100 boutons sur le formulaire.
5. ce point est lié au point 3.
6. Une ligne également avec la bonne approche au point 3.
7 - Vous avez entre les mains toute la puissance de C#, dont l'échelle, dont vous semblez n'avoir aucune idée, est énorme.
Sans vouloir vous offenser, je suis désolé d'être hors sujet.
Vous prenez l'exemple le plus SIMPLE et vous l'extrapolez en pensant 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 créer une mémoire TOTAL à 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.
La conclusion est complètement fausse.
Le problème est que j'ai VRAIMENT fait ce dont je parle. Et je connais la complexité de l'organisation de l'interaction entre un programme MT complexe et un programme tiers complexe.
Et l'approche du profane est généralement de dire "C'est facile...". Quel est le problème ? C'est comme ceci, c'est comme cela...".
Donnez-moi un exemple de connexion d'un programme MT complexe à un formulaire Windows complexe, où le programme peut.. :
Le problème est que j'ai VRAIMENT fait ce dont je parle. Et je connais la complexité de l'organisation de l'interaction entre un programme MT complexe et un programme tiers complexe.
Et l'approche du profane est généralement de dire "C'est facile...". Quel est le problème ? C'est comme ceci, c'est comme cela...".
Donnez-moi un exemple de connexion d'un programme MT complexe à un formulaire Windows complexe, où le programme peut.. :
Si c'était le cas, vous ne poseriez pas de questions comme aujourd'hui. Apprenez le C# et faites-le vous-même. Comment connecter la dll et appeler les méthodes qu'Igor a montré hier.
1. Quel est le problème ? C'est le choix du type de projet lorsque vous le créez.
2. Comme on le voit dans l'exemple montré par Igor, la connexion se fait en une ligne, même l'importation n'est pas décrite.
3. une méthode est écrite une fois, sauvegardée dans un fichier, et ensuite elle est utilisée dans tous les projets sans aucune modification.
4. Probablement, c'est nécessaire, mais ils sont simples. Tous ne seront probablement pas nécessaires, l'interaction entre les éléments de contrôle en c# sera différente, et il peut être nécessaire de placer un événement, et il y aura 100 boutons sur le formulaire.
5. ce point est lié au point 3.
6. Une ligne également avec la bonne approche au point 3.
7 - Dans vos mains, toute la puissance de C#, dont vous semblez n'avoir aucune idée de la gamme, est énorme.
Dmitry, utilisez l'ÉNORME puissance de C# et créez une application pas très complexe avec un formulaire, qui interagit avec l'application MT et exécute ces éléments :
Dimitri, utilisez la grande puissance de C# et créez une application pas très complexe avec un formulaire qui interagit avec l'application MT et exécute ces éléments :
J'ai beaucoup de choses à faire. Mais vous pouvez continuer dans vos délires.
Et oh oui, un miracle inédit en programmation - pour faire quelque chose, il faut écrire une fonction pour le faire.
J'ai des choses à faire. ...
OK, peut-être qu'Igor le fera alors...
OK, peut-être qu'Igor le fera alors...
Igor en a déjà trop montré. Et j'en ai trop dit.