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
Cette photo est-elle un exemple ?
Ok, je vais me débrouiller tout seul.
(L'homonyme s'est probablement laissé emporter... )))
J'ai écrit dans le post précédent : tout est fait avec les outils internes de VS. J'utilise VS 2017 Community. Au début du projet, la bibliothèque DllExport avec Nuget y est connectée. Après avoir compilé le projet, rien ne doit être finalisé à la main, du mot TOUT.
Je ne veux pas affirmer quoi que ce soit, mais il y a un mais... Ou mieux encore, une question.
Un projet a "une bibliothèque Nuget" attachée à lui. De nombreuses librairies du framework sont connectées au projet C#. Cependant, le programme C# ne fonctionnera pas sans ce cadre. La banalité, en général.
Je suppose que lors du portage sur un autre ordinateur, non seulement le programme lui-même, mais aussi "une librairie de Nuget" seront nécessaires. Je ne sais pas comment l'intégrer là sans VS.
Voici un exemple. Les dernières versions du framework (toujours pour VS 2015) n'ont pas de sockets et doivent être installées à partir du même Nuget en plus. Le transfert d'un programme C# vers un autre ordinateur où les sockets ne font pas partie du framework est impossible. Dans un premier temps, vous devez vous soucier de réinstaller la bibliothèque Sockets. D'ailleurs, je n'ai aucune idée de la manière de le faire sans VS - je n'ai jamais été confronté à une telle tâche. Cela peut probablement être fait par une ligne de commande. C'est facile, mais c'est un casse-tête pour l'utilisateur moyen. Ie ... pour transférer le programme doit encore mess avec l'installateur ou au moins un lot + instruction.
Je ne veux rien affirmer, mais il y a un mais... Ou mieux, une question.
Une "single Nuget lib" est connectée à un projet. De nombreuses librairies du framework sont connectées au projet C#. Cependant, le programme C# ne fonctionnera pas sans ce cadre. La banalité, en général.
Je suppose que lors du portage sur un autre ordinateur, non seulement le programme lui-même, mais aussi "une librairie de Nuget" seront nécessaires. Je ne sais pas comment l'intégrer là sans VS.
Voici un exemple. Les dernières versions du framework (toujours pour VS 2015) n'ont pas de sockets et doivent être installées à partir du même Nuget en plus. Le transfert d'un programme C# vers un autre ordinateur où les sockets ne font pas partie du framework est impossible. Dans un premier temps, vous devez vous soucier de réinstaller la bibliothèque Sockets. D'ailleurs, je n'ai aucune idée de la façon de le faire sans VS - je n'ai jamais été confronté à une telle tâche. Cela peut probablement être fait par une ligne de commande. C'est simple, mais pour l'utilisateur moyen, c'est un casse-tête. Ie ... pour transférer le programme doit encore mess avec l'installateur, ou au moins un batnik + instruction.
La seule question qui se pose ici est de savoir comment les modules complémentaires sont connectés. Si elles sont connectées sous la forme de bibliothèques externes, elles doivent bien sûr être "transportées". Et s'ils sont intégrés en tant qu'utilisateurs, alors tout ceci est compilé comme faisant partie du produit, comme cela se passe dans mql avec include
L'absence d'interface graphique dans les logiciels de trading MT est un obstacle à la croissance de l'algotrading.
Nulle part ailleurs l'algotrading ne se développera autant que dans un environnement MQL.
Il est trop difficile de reprendre l'interface graphique d'un autre environnement logiciel. En utilisant les vôtres, aussi. Les bibliothèques graphiques ne sont pas destinées aux débutants.
Si l'interface graphique était accessible à tous, le marché s'épanouirait en couleurs vives.
L'imagination humaine trouvera des applications pour de nouvelles fonctionnalités.
Cela a toujours été le cas.
L'absence d'interface graphique dans les logiciels de trading MT est un obstacle à la croissance de l'algotrading.
Nulle part ailleurs l'algotrading ne se développera autant que dans un environnement MQL.
Il est trop difficile de reprendre l'interface graphique d'un autre environnement logiciel. En utilisant les vôtres, aussi. Les bibliothèques graphiques ne sont pas destinées aux débutants.
Si l'interface graphique était accessible à tous, le marché s'épanouirait en couleurs vives.
L'imagination humaine trouvera des applications pour de nouvelles fonctionnalités.
Ça a toujours été comme ça.
Et quelles sont les suggestions ?
Et quelles sont vos suggestions ?
Ne faites pas attention à moi, juste un démagogue, dans sa capacité habituelle).
J'ai beaucoup blessé ton ego.)
A propos de la démogoguerie. Vous n'avez qu'une seule chose dans votre profil sur toutes vos pages -"Yuriy Asaulenko a ajouté un sujet". Vous ne créez rien d'autre que des sujets.
Et qui est un démogogue ici ?
Tu devrais au moins créer quelque chose. Tu aurais pu les surprendre avec quelque chose.
RIEN. Rien que des paroles sans fin et inutiles sur ce forum.
Vous êtes le vrai démogogue.
Quel genre de suggestions ?
Des suggestions ? - Faites ce dont vous avez commencé à parler dans ce fil. Développer la création d'une interface utilisateur graphique en mode graphique.
Et n'oubliez pas ce sujet.
Développez votre vision de l'avenir.
Et quelles sont vos suggestions ?
Alexei, avez-vous pu créer une dll avec le formulaire ?
Ne faites pas attention à lui, c'est juste un démagogue dans son rôle habituel).
Ce n'est pas vrai, j'ai reçu une commande aujourd'hui via VK pour un panneau, le gars veut strictement du C++/C3 externe pour son choix. J'ai dit Sharp, bien sûr.