Mon approche. Le noyau est le moteur. - page 170
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
Hilarant :))))
Bien joué, vous******* prenez une tarte sur l'étagère.
OK, je vais essayer de le justifier :
Si l'on suit votre solution, l'utilisateur devra toujours copier le code source de la classe statique dans le projet, qui traduira les événements, exécutera le formulaire dans un thread bien distinct, etc. En outre, vous devez lier statiquement le formulaire à cette classe, c'est-à-dire saisir explicitement le nom de la classe de formulaire et de ses composants. C'est-à-dire modifier explicitement le code de votre couche lorsqu'un formulaire est modifié ou qu'un élément est ajouté. En d'autres termes, une solution simple et directe, qui fonctionnerait bien pour démontrer l'interaction avec un formulaire spécifique, ce que vous avez montré. Dans un cas généralisé, il est préférable de séparer la logique de contrôle de la logique d'affichage, ce que j'ai fait. En outre, cette séparation vous permet de protéger le contrôleur contre toute modification non qualifiée.
Voici un commentaire qui répond exactement à la question de savoir pourquoi il a été fait de cette façon et pas de l'autre :
vous avez probablement raison, il est plus facile pour un utilisateur d'esquisser des éléments graphiques dans un formulaire dans VS2017, puis de vérifier en exécutant sa création dans VS, après s'être assuré que "tout tourne", il peut passer à la création d'un programme d'interaction en .Net et MT5
...
Votre méthode est probablement plus pratique.
Exactement. Il y aura une énorme base de données de cyb-codes avec des images. Allez-y, sélectionnez, obtenez le code, insérez dans le constructeur, obtenez le noyau avec les fichiers de connexion. Et la connexion est déjà pensée et beaucoup plus facile.
Ainsi, chaque formulaire est dans un fichier séparé. Même si c'était plus simple, les possibilités sont limitées.
Là aussi, chaque formulaire est dans un fichier séparé. Même si c'était plus simple, les possibilités sont limitées.
Pour être honnête, je n'ai pas encore totalement maîtrisé la technologie, et je ne peux donc pas encore me prononcer sur les limites de la solution de Vasiliy.
Basil, ne le prenez pas mal, mais un panel comme celui-ci :
J'ai à peu près ce genre de code :
Ce code peut simplement être transmis à l'autre, ou mis dans une base commune et il n'est pas nécessaire de dessiner un formulaire à chacun spécialement.
Je l'ai collé dans le constructeur et j'ai obtenu une autre fenêtre avec tous les paramètres et connexions de l'élément.
Peter, pour dessiner le même panneau que toi, je dois apprendre ton langage de balisage. L'utilisateur n'a besoin que d'une souris et de compétences de base pour dessiner ce panneau dans Visual Studio. Vous sentez la différence ?
Pour être honnête, je n'ai pas encore totalement maîtrisé la technologie, et je ne peux donc pas encore me prononcer sur les limites de la solution de Vasiliy.
Et je n'ai pas écrit sur les limites de la solution de Vasiliy.
Peter, pour dessiner le même panneau que le tien, je dois apprendre ton langage de balisage. L'utilisateur n'a besoin de rien pour dessiner ce panneau dans Visual Studio, juste une souris et des connaissances de base. Vous sentez la différence ?
Vasily, une personne étudie mon langage de balisage et écrit le panneau. Des milliers d'autres voient la photo du panneau et prennent le cyber-code tout fait. Ils le collent dans mon constructeur et obtiennent le panneau dans leur programme.
Pré-lu, mais je vais continuer à relire pour entrer dans les détails.
1. Pourquoi l'article parle-t-il de 5 demandes par seconde ? J'ai une fréquence de 30ms.
2. Pouvez-vous me montrer à quoi ressemble une connexion à un tableau de mille cellules ?
3 D'après ce que je comprends, appeler les éléments du formulaire par leur nom envoyé à la fonctionGuiController::SendEvent ? Faut-il préciser tous les paramètres ? Nom, événement, valeur ? Encore quelques zéros... Et dans le timer pour faire une boucle sur les événements ?
En d'autres termes, l'utilisateur crée lui-même la file d'attente des événements et la transmet ensuite au contrôleur dans le timer ?
Je dois vous remercier pour la grande promotion de mon sujet.
1) Cela ne fait aucune différence. Vous pouvez le régler sur la fréquence de votre choix.
2) Les tables ne sont pas supportées maintenant (excellente raison pour vos applaudissements d'ailleurs :)
3) Oui, l'adressage par nom, vous devez spécifier tous les paramètres. Mais, et c'est le plus important, il n'existe pas de modèle d'événement monolithique unique. Vous voulez votre propre modèle, vous êtes le bienvenu. Il est élémentaire de le faire. Mais vous ne pouvez pas vous passer de minuterie.
La file d'attente d'événements est un algorithme généralisé pour le traitement fiable des événements. L'utilisateur ne compose rien ; les événements qu'il génère arrivent d'eux-mêmes dans la file d'attente. La file d'attente elle-même ne comporte qu'un seul événement dans 99,9 % des cas.
OK, je vais essayer de le justifier :
Si nous suivons votre solution, l'utilisateur devra toujours copier le code source de la classe statique dans le projet, qui traduira les événements, exécutera le formulaire dans un thread séparé, etc. En outre, vous devez lier statiquement le formulaire à cette classe, c'est-à-dire saisir explicitement le nom de la classe de formulaire et de ses composants. C'est-à-dire modifier explicitement le code de votre couche lorsqu'un formulaire est modifié ou qu'un élément est ajouté. En d'autres termes, une solution simple et directe fonctionnerait bien pour démontrer l'interaction avec un formulaire spécifique, ce que vous avez montré. Dans un cas généralisé, il est préférable de séparer la logique de contrôle de la logique d'affichage, ce que j'ai fait. De plus, cette séparation vous permet de protéger le contrôleur contre toute modification non qualifiée.
Voici un commentaire qui répond exactement à la question de savoir pourquoi il a été fait de cette façon et pas de l'autre :
Le plus gros problème est le lancement du formulaire dans un thread séparé, mais il est résolu par deux lignes de code, donc au final ce n'est pas un problème. En outre, dans mon exemple, j'ai délibérément ouvert le deuxième formulaire, pour montrer à quel point c'est facile et simple à faire, et comment vous pouvez ouvrir un nombre quelconque de formulaires dans des fils séparés.
Et ce qui est souligné dans la citation - est-ce que le foin et la paille sont la même chose ? Oui ! Pour manger une banane, vous devez éplucher la peau.
Pour être honnête, je n'ai pas encore totalement compris la technologie, et je ne peux donc pas encore me prononcer sur les limites de la solution de Vasiliy.
Il n'y a pas de limite de capacité, tout est limité ni plus ni moins que la fonctionnalité des éléments graphiques de Windows, lisez l'article de la section"Sous le capot du GuiController", ajoutez les contrôles nécessaires dans le form designer et quels événements vous devez recevoir dans MT5, ajoutez-les à <element - list of event handlers>.
2) Les tableaux ne sont pas supportés maintenant (grande raison pour votre réjouissance d'ailleurs :)
Je vais aussi féliciter Peter, j'ai fait fonctionner la table dans un formulaire séparé dans un .dll sur .Net, les événements de clic droit, le tri, et d'autres charmes dataGridView tout le travail, a fait en partie des expériences de table comme le terminal, mais plutôt capricieux et lent dataGridView , j'ai essayé beaucoup de choses avec elle ( et rempli un clone datatable et ensuite copié sur le datatable qui est lié à un dataGridView et . et de googler pendant une semaine et d'expérimenter, tandis que avec dataGridView un fiasco complet - vous ne pouvez pas écrire à elle plus de 3-5 secondes) un tableau 10x11 est déjà critique, bien que le formulaire avec le tableau et fonctionne dans un thread séparé
SZY : Il m'a fallu 2 heures pour attacher StringGrid à MT4 en Delphi, je n'étais pas du tout inquiet de la façon dont cela fonctionnait, mais tout était en train de voler, cependant avec Microsoft dataGridView est un problème, aujourd'hui je vais essayer d'expérimenter avec SourceGrid, selon les retours d'information il est plus rapide que dataGridView