Mon approche. Le noyau est le moteur. - page 36
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
Combien de temps cela vous prendrait-il de faire une fenêtre comme celle-ci ? :)
Une bibliothèque standard peut-elle le faire ? )
Mais si je cherche dans Google des textures prêtes à l'emploi et que je les lie à la bibliothèque MQL standard, je le ferai certainement en un jour. Je crée habituellement des éléments pratiques, comme des barres d'outils, des boutons, des cases à cocher, c'est-à-dire des contrôles sur lesquels les utilisateurs cliqueront pour obtenir des résultats.
Mais vous devez faire la distinction entre ce que fait le terminal et ce que fait le graphique dans l'EA - pourquoi répéter les capacités du terminal ? .... Eh bien, si vous voulez faire une perversion, vous devez payer pour cela, si l'utilisateur le veut, vous pouvez le faire.
Si nous parlons de beaux boutons, de calendriers, de boîtes de progression, je mettrais tout en .dll et en quelques jours (en Delphi), je créerais une .dll de composants prêts à l'emploi pour la mise en page du client - elle serait plus cool que la vôtre et aurait le même aspect et les mêmes fonctionnalités que les célèbres logiciels (gestion des bases de données, graphiques, animation... et ainsi de suite) et la main d'œuvre nécessaire ne serait pas comparable à la vôtre.
Vous devez être capable d'utiliser une solution toute faite ou être dans la tendance ! Si les développeurs ont pris en charge les bibliothèques .NET, vous devez alors chercher vos propres solutions avec de beaux calendriers et des barres de progression.
;)
Et essayez de faire en sorte qu'en appuyant sur un bouton, un ensemble de contrôles s'affiche, et en appuyant sur un autre bouton, un autre contrôle. En même temps, la fenêtre peut être réduite et agrandie. On suppose également qu'il pourrait y avoir beaucoup de variantes.
Masquer l'élément : m_button.Hide() ;
afficher l'élément : m_button.Show() ;
et je ne me souviens pas, mais il a la propriété Enable - si c'est Enable, nous pensons que l'élément est actif et nous traiterons tous les clics dessus ; si c'est disabled, alors nous l'avons caché et il n'est pas visible - retour immédiat
J'ai quelque chose à la maison quelque part, mais je ne l'ai pas sous la main pour le moment.
Le produit est conçu pour remplacer le trading manuel. La question est de savoir dans quelle mesure la négociation manuelle est encore répandue et ce que l'on peut offrir à ceux qui la pratiquent.
Il appartient aux programmeurs d'écrire des systèmes semi-automatiques qui automatisent et renforcent les capacités de ceux qui négocient manuellement. Sur ce point, ils gagneront de l'argent.
Exactement, j'ai déjà attiré l'attention sur ce point.
Ce n'est pas ton créneau, Peter ! Les programmeurs qui écrivent des systèmes semi-automatiques, et qui vont les VENDRE, ne toucheront jamais à la bibliothèque d'un autre. Tout d'abord, en raison des problèmes de support - si quelque chose ne va pas - vous devez contacter l'auteur de la bibliothèque, et vous devrez peut-être vous débrouiller tout seul (et étant donné votre style d'accès global - il sera très difficile de calculer les erreurs). Aucun des programmeurs qui écrivent des systèmes pour les autres n'en a besoin. Il est beaucoup plus raisonnable pour eux d'écrire quelque chose de leur cru.
Votre créneau est celui des programmeurs qui préfèrent trader manuellement. Votre bibliothèque sera très intéressante pour eux. Mais combien d'entre eux sont présents sur le forum ?
Bien sûr, le code est gros. Mais c'est extrêmement simple.
L'essentiel est que les éléments dont les propriétés sont déjà définies (taille, couleur, gradient) peuvent être simplement extraits du code et copiés dans d'autres fenêtres.
Pas de syntaxe, pas de cours, etc... Ils ont juste pris un élément, ou un groupe d'éléments, ou la fenêtre entière et l'ont collé n'importe où. En un seul morceau.
Ensuite, changez quelque chose et vous obtenez un nouvel élément, groupe d'éléments ou fenêtre.
Il est facile à utiliser pour la première fois. Mais pour la détection des erreurs, il est très, très malveillant. Lorsque vous écrivez du code pour la première fois, ce n'est pas un gros problème - en règle générale, vous avez un exemple ou de l'aide, et surtout, vous êtes "dans le processus" et gardez toutes ces subtilités à l'esprit.Mais quand vous avez besoin de changer quelque chose, ou, en outre, apparaissent des erreurs - pour chaque ligne doivent aller à l'aide, et chaque fois s'assurer que "tout est OK ici", jusqu'à ce qu'une (la loi de la malchance - la dernière) ligne est soudainement apparu que vous foiré quelque chose. Et à ce moment-là, vous maudirez le monde en déboguant un tel "code avec accès global au noyau".
Si l'ordre n'est pas important, il n'y a pas d'infobulles. Et lorsque vous appelez une fonction ou un constructeur de classe avec des paramètres, le compilateur fait des allusions par paramètres. Et vous savez, c'est une aide très importante. L'approche standard est donc un atout indéniable.
Au fait, oui, c'est une très belle chose. Je peux le confirmer.
Et un autre avantage de l'encapsulation : lorsque vous vous adressez à des fonctions distinctes avec des paramètres distincts, vous savez déjà ce qui doit lui être transmis par son nom. Et si vous passez une structure - elle est également visible par le nom des champs.
En cas d'accès à un tableau global avec des index simples, même si l'ordre est arbitraire, les données peuvent être mélangées très facilement, ce qui facilite les erreurs.
C'est vrai, j'ai attiré l'attention sur ce point.
Ce n'est pas ton créneau, Peter ! Les programmeurs qui écrivent des systèmes semi-automatiques et qui vont les VENDRE, ne toucheront jamais à la bibliothèque d'un autre. Tout d'abord, en raison des problèmes de support - si quelque chose ne va pas - vous devez contacter l'auteur de la bibliothèque, et vous devrez peut-être vous débrouiller tout seul (et étant donné votre style d'accès global - il sera très difficile de calculer les erreurs). Aucun des programmeurs qui écrivent des systèmes pour les autres n'en a besoin. Il est beaucoup plus raisonnable pour eux d'écrire quelque chose de leur cru.
Votre niche est celle des programmeurs qui préfèrent trader manuellement. Votre bibliothèque sera très intéressante pour eux. Mais combien d'entre eux sont présents sur le forum ?
À ce propos, pour une raison quelconque, personne n'a remarqué le décalage entre l'objectif de Pierre et son créneau. Il veut supplanter le commerce manuel. Mais il fait son travail pour ceux qui font du commerce manuel. Un tel objectif me semble étrange : " Je vais vous donner quelque chose qui va tuer votre arrangement commercial habituel... ". Je suis un type gentil qui est venu briser tout ce à quoi vous étiez habitué - maintenant vous allez travailler selon mes règles". Cela lui apportera-t-il le succès ?
"Tu es un peu bizarre, Billy"...
Vous ne comprenez rien. :) L'objectif de Peter est de remplacer les traders manuels qui ouvrent des positions avec la touche F9 par une couche agréable entre le trader et le terminal. Et si le trader n'a jamais perdu son dépôt d'une manière agréable auparavant, il le fera joliment avec cette couche. Le dépôt sera réduit, tandis que le trader profitera de la beauté esthétique du panneau. Et Peter, en tant qu'artiste, est intéressé par la beauté esthétique, et vous gâchez son inspiration avec votre pragmatisme.
....
Cela m'a rappelé un de mes amis. Elle a acheté un nouvel ordinateur et s'en vante. Je lui ai demandé. Et combien de RAM il possède, quelle vitesse d'horloge et autres spécifications. Elle répond. Je ne sais pas, mais c'est si beau. :)
Peter, en tant qu'artiste, ne pense qu'à la beauté esthétique, et vous gâchez son inspiration avec votre pragmatisme.
Oui, j'ai déjà demandé où l'on peut appliquer ces magnifiques dégradés que Peter a montré dans la démo... Mais... Je n'ai pas encore vu d'avantage ou même de commodité à les utiliser.
Et avant Peter, il y avait un participant ici aussi - il avait même des indicateurs graphiques intéressants qui semblaient utiliser toutes ces images colorées en dégradé... Je l'ai aussi interrogé sur sa candidature... il a promis de le présenter, mais je suppose que ça a été bloqué...
Eh... N'importe qui peut faire du mal à un artiste...
Essayez de faire apparaître un ensemble de contrôles lorsque vous cliquez sur un bouton, et un autre ensemble de contrôles lorsque vous cliquez sur un autre bouton. En même temps, la fenêtre peut être minimisée et maximisée. On suppose également qu'il pourrait y avoir beaucoup de variantes.
Il serait intéressant de demander à Peter, comment il pourrait résoudre ce problème.
trouvé dans l'aide, cela ressemble à ceci
Cette bibliothèque nécessite Visual Studio, qui générera le fichier de données pour la bibliothèque.
Et l'utilisateur n'aura qu'à façonner ses fenêtres dans le programme - C'est la seule solution !
En effet, la difficulté avec toutes les bibliothèques (frameworks) est que l'utilisateur doit "réapprendre" ses fonctions et paramètres.
Mais c'est aussi un avantage :
Les bibliothèques dans toutes les langues sont créées pour GAGNER DU TEMPS !
Lorsque la partie principale du code est déjà écrite et déboguée. Et l'utilisateur (le programmeur) utilise ses possibilités.
Que dire de la bibliothèque standard deMetaQuotes- combien de personnes l'utilisent ? !La plupart, surtout les débutants.
Il en va autrement lorsqu'un programmeur "veut" créer sa propre bibliothèque. Et il/elle l'utilisera. - Comme vous l'avez dit plus haut : il est plus facile pour le programmeur d'utiliser sa propre bibliothèque, qu'il peut maintenir lui-même, au lieu d'attendre l'aide de l'auteur ......
Pour que le produit soit en demande, il y a deux façons de procéder :
Pour le premier point, tout ce dont vous avez besoin est de l'argent.
Le deuxième point nécessite un nouveau produit qui suscite l'intérêt.
Tout ce qui ne suscite pas d'intérêt - mourra sans trouver son application et son utilisateur. Et sans l'utilisateur et l'auteur de la bibliothèque, il n'y aura pas d'intérêt à la développer.
Ce cercle vicieux découragera à jamais l'auteur et l'utilisateur.
Il est facile à utiliser pour la première fois. Mais pour la détection des erreurs, il est très, très malveillant. Lorsque vous écrivez du code pour la première fois, ce n'est pas un gros problème - en règle générale, vous avez un exemple ou de l'aide, et surtout, vous êtes "dans le processus" et gardez toutes ces subtilités à l'esprit.Mais quand vous avez besoin de changer quelque chose, ou, en outre, apparaissent des erreurs - pour chaque ligne doivent aller à l'aide, et chaque fois s'assurer que "tout est OK ici", jusqu'à ce qu'une (la loi de la malchance - la dernière) ligne est soudainement apparu que vous foiré quelque chose. Et à ce moment-là, vous maudirez le monde en déboguant un tel "code avec accès global au noyau".
George, je t'ai dit plusieurs fois qu'il y a un langage de balisage tout fait. Pourquoi quelqu'un voudrait-il jouer avec le code ? Il comprend la langue et fait ce qu'il faut.
Si l'utilisateur ne dispose pas de suffisamment de graphiques et a besoin d'une animation- il peut le faire dans son application.
Une dernière chose : le marché sera TOUJOURS inondé. Rien ne pourra changer ce fait. Eh bien, laissez-les se vider avec de beaux et puissants semi-automatiques. Au moins, ils se sentiront mieux moralement).
Plus sérieusement,aucun programme ne changera le rapport entre ceux qui drainent et ceux qui gagnent.
Mais même après avoir perdu de l'argent, ils continueront à utiliser un programme semi-automatique. Parce que ce n'est pas O N D O R A C E.
Il peut donc être loué.