Mon approche. Le noyau est le moteur. - page 140
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
Oui. Exactement. Toutes les informations nécessaires pour que le moteur puisse reproduire une interface graphique particulière et travailler avec elle. Je suis en train de l'installer directement dans le moteur, et de le rendre chargeable à partir du fichier que le constructeur imprime.
Comme c'est compliqué et déroutant.
Ne serait-il pas plus facile pour l'utilisateur de vos chaudières shaitan de faire en sorte qu'après que l'utilisateur ait construit les formulaires, fenêtres et éléments requis, il lui suffise de sortir un fichier mqh pour se connecter au programme via #include ? Le fichier contient déjà OnChartEvent(), OnTimer(), OnTick() et d'autres éléments de liaison. Il ne reste plus qu'à lui prescrire les actions nécessaires, ce qu'il devra de toute façon faire, mais il faut aussi apprendre son langage de balisage. Sinon, vous n'avez pas besoin de tout cela - écrivez simplement en mql ce dont vous avez besoin dans le fichier mqh généré et soyez heureux.
Vous avez pris le parti de créer un langage de balisage et de le connecter en utilisant un langage que l'utilisateur ne comprend pas pour une raison quelconque. Cette solution n'attirera pas les utilisateurs de la langue mql vers le produit.
Il semble, en regardant les merveilles de ce fil - que le plus grand effort mental que l'on tend à faire est de rester un imbécile.
Mais cela écrasera toutes les modifications et liaisons de l'utilisateur qui sont dans les événements ?
Dès que l'interface graphique change, l'utilisateur appuie sur un bouton et imprime les nouveaux fichiers. Le moteur charge les nouveaux noyaux et l'application utilisateur doit connecter les fichiers d'appariement mis à jour.
Dans ce cas, il suffit de remplacer un fichier (propriétés de la conjonction) et de reconnecter l'autre fichier. Mais, il est possible de copier du code déjà écrit depuis un fichier précédent.
L'essentiel est de ne pas remplir les fichiers de connexion avant d'avoir choisi l'interface graphique. Si de nouvelles fenêtres sont ajoutées, cela n'aura pratiquement aucune incidence. Si les anciennes fenêtres et les éléments sont modifiés, il faudra peut-être réécrire le code dans le programme également.
Tout cela se passe dans le constructeur. Le code KIB est écrit et le fichier est recompilé.
Voici comment travailler avec le constructeurhttps://www.mql5.com/ru/blogs/post/717782.
Regardé... Des erreurs stupides et enfantines avec les noms des fichiers et des dossiers, vous travaillez dans l'éditeur comme si vous l'ouvriez pour la première fois...
Et ce que j'ai réalisé, c'est que ce n'est pas du tout un constructeur. Je pensais que vous aviez un constructeur visuel...
Et vous appelez ce concept une percée ? D'où et vers où ?
Comme c'est compliqué et déroutant.
Ne serait-il pas plus facile pour l'utilisateur de votre shaitan-boiler de faire en sorte qu'après que l'utilisateur ait construit les formulaires, fenêtres et éléments requis, il sorte simplement un fichier mqh pour se connecter au programme via #include ? Le fichier contient déjà OnChartEvent(), OnTimer(), OnTick() et d'autres éléments de liaison. Il ne reste plus qu'à lui prescrire les actions nécessaires, ce qu'il devra de toute façon faire, mais il faut aussi apprendre son langage de balisage. Sinon, vous n'avez pas besoin de tout cela, écrivez simplement en mql ce dont vous avez besoin dans le fichier mqh généré et soyez heureux.
Vous vous êtes engagé dans la voie de la création d'un langage de balisage et de connectivité utilisant un langage que l'utilisateur ne comprend pas pour une raison quelconque. Cette solution n'attirera pas les utilisateurs de la langue mql vers le produit.
Au fait, oui.
J'ai exactement la même chose en recompilant. Bien sûr, je n'ai jamais fait de fichiers MQH prêts à l'emploi, je me contente d'en écrire de simples en texte, puis à partir de ceux-ci je transfère les textes des procédures d'initialisation aux modules de base, mais l'idée est la même.
Peter, vraiment - cela faciliterait la vie de vos utilisateurs si, au lieu des paramètres que vous devez vous rappeler comment utiliser, un fichier MQH prêt à l'emploi avec des paramètres prêts à l'emploi était généré !
Et c'est votre concept que vous appelez une percée ? D'où et vers où ?
Il s'agit d'une percée - des personnes qui veulent des Expert Advisors prêts à l'emploi avec un seul bouton "chop dough" (ou au moins avec deux boutons, un autre - "chop huge dough") - aux personnes qui traderont en mode semi-automatique, ouvrant des trades, les accompagnant et les clôturant avec l'aide des composants visuels de Peter !
Je suis convaincu que si de telles personnes apparaissent, ce sera une véritable percée.
Je doute simplement que ce soit possible. Les gens sont paresseux par nature, et pour faire du commerce manuel (même semi-automatique) - il faut beaucoup d'expérience, et où le beau monde local la trouve-t-il ?
Au fait, oui.
C'est exactement ce que je fais lorsque je recompile. Je ne fais pas de fichiers MQH prêts à l'emploi, j'en écris en texte brut, et ensuite à partir d'eux je transfère le texte des procédures d'initialisation aux modules principaux, mais l'idée est la même.
Peter, vraiment - cela faciliterait la vie de vos utilisateurs, si au lieu de paramètres, dont vous devez vous rappeler comment les utiliser - un fichier MQH prêt à l'emploi avec des paramètres prêts à l'emploi était généré !
Je n'ai pas compris de quels paramètres il s'agissait. Mais je ferai ce que je peux.
Expliquez plus en détail.
Pas de documentation, donc liens de mémoire (quelque part dans les profondeurs de la piste) :-)
Vous générez un fichier avec une fonction avec de nombreux interrupteurs imbriqués qui distribue des messages des éléments de l'interface à "pressé" "relâché". L'utilisateur tape ses réactions aux événements qui s'y déroulent.
Vous avez modifié l'interface, maintenant qu'en est-il de ce fichier ?
Combien de travail, par exemple, un utilisateur devrait-il faire pour diviser le panneau en deux fenêtres - l'une contenant des boutons et l'autre un tableau (afin, par exemple, que l'utilisateur puisse la fermer et ne pas traîner à l'écran) ?
Et, par exemple, certaines colonnes devraient être interverties. C'est tout à fait typique - créer une mise en page, l'utiliser, changer l'apparence pour une autre plus pratique.
Je ne sais pas de quels paramètres on parle. Mais je ferai ce que je peux.
L'idée est qu'après la construction de tous les formulaires, fenêtres, éléments visuels, un fichier MQL prêt à l'emploi serait créé, destiné à une compilation directe.
Si je comprends bien, les utilisateurs doivent saisir toutes les tailles, coordonnées, retraits... C'est un travail très fastidieux et fastidieux. Ce serait bien si c'était automatisé. Le résultat serait un fichier MQH prêt à être recompilé.
Je ne sais pas de quels paramètres on parle. Mais je ferai ce que je peux.
Apprenez la POO, et vous aurez fait depuis longtemps, et pas seulement ce que vous pouviez, mais beaucoup plus - un énorme espace pour la créativité, dont vous n'êtes même pas conscient maintenant. Rapidement, efficacement et professionnellement.
Mais pendant des années, vous avez bricolé avec votre moteur constamment gonflé.
Et si vous êtes fier de la quantité de code que vous avez écrit, vous êtes un "Indien" de la programmation. Ce n'est pas une injure - il suffit de chercher cette définition, elle correspond exactement à ce que vous faites.
Vous pouvez écrire du code de mille lignes et écrire du code de cent lignes, et les deux feront le même ensemble d'actions. Mais il est beaucoup plus difficile de modifier ou de compléter un code gonflé qu'un code non gonflé. Mais vous préférez vous vanter du nombre de lignes que vous avez écrites (en frappant Nikolaï dans le nez avec), qualifiant tout cela d'énorme projet. Comme un enfant, bon sang.