![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Désolé, j'ai failli oublier : Joyeux anniversaire !
Santé et bonne chance !
Ne buvez pas trop.
Merci, un peu aujourd'hui.
Est-ce que je vais m'excuser auprès de Dimitri ? Il est prêt, n'est-ce pas ?
Question difficile.
Joyeux anniversaire, au fait !
Notez que Sharpe dispose d'un puissant système de code autogénéré. Cela vous permet de dessiner un formulaire dans l'éditeur et d'obtenir un texte de programme généré automatiquement, en remplissant un tas de propriétés de chaque élément, en commençant par son positionnement et en terminant par son apparence. L'argument du "nombre de lignes de code" ne fonctionne donc pas du tout.
Il y a beaucoup plus dans Sharp qu'aucun autre moteur graphique pour MQL, il est donc ridicule de se battre avec Sharp.
Question difficile.
Joyeux anniversaire, au fait !
Merci.
Notez que Sharpe dispose d'un puissant système de code autogénéré. Cela vous permet de dessiner un formulaire dans l'éditeur et d'obtenir un texte de programme généré automatiquement, en remplissant un tas de propriétés de chaque élément, en commençant par son positionnement et en terminant par son apparence. L'argument du "nombre de lignes de code" ne fonctionne donc pas du tout.
Il y a beaucoup plus dans Sharp qu'aucun autre moteur graphique pour MQL. C'est pourquoi il est plutôt ridicule de se battre avec Sharp.
Vous ne me connaissez pas encore...)))
Notez que Sharpe dispose d'un puissant système de code autogénéré. Cela vous permet de dessiner un formulaire dans l'éditeur et d'obtenir un texte de programme généré automatiquement, en remplissant un tas de propriétés de chaque élément, en commençant par son positionnement et en terminant par son apparence. L'argument du "nombre de lignes de code" ne fonctionne donc pas du tout.
Il y a beaucoup plus dans Sharp qu'aucun autre moteur graphique pour MQL. C'est pourquoi il est amusant de se battre avec Sharp.
Shh, c'est ce que j'ai dit hier à propos de Sharp et ça a commencé..... Mais ne donnez pas à Peter la tâche de dessiner une forme ovale ou il sera dans l'impasse )))).
SZY : C'est la troisième fois de ma vie que j'ouvre Sharp, ce n'est pas différent de Delphi, il suffit de tirer un composant, de cliquer - écrire un gestionnaire, vous le trouvez en une seule recherche..... tout comme d'habitude, la seule raison pour laquelle Sharpe était intéressant, il semble que Python peut être déployé sur elle, bien, il y aura quelque chose à Google au moins ;)
SZY : la troisième fois de ma vie que j'ouvre Sharp, eh bien, ce n'est pas différent de Delphi, tirer un composant, cliquer - écrire un handler, ce que vous ne savez pas en une seule recherche trouver.... tout comme d'habitude, la seule raison pour laquelle Sharpe était intéressant, il semble que Python peut être déployé sur elle, bien, au moins quelque chose à google ;)
Au fait, pour le plaisir de la curiosité, vous pouvez faire glisser le formulaire depuis Delphi (depuis Lazarus). Les principes y sont les mêmes :-)
Sauf que MT et ### sont censés avoir une relation plus étroite jusqu'au moment des fiançailles, et que Delphi pleure sur la touche, mais pas plus mal....
vous pouvez d'ailleurs, pour le plaisir de la curiosité, tirer un formulaire de Delphi (de Lazarus). Les principes y sont les mêmes :-)
A moins que MT et ### soient censés se rapprocher jusqu'aux fiançailles, et que Delphi pleure sur la touche, mais sans plus...
hélas, pire, pour que le .dll de Delphi devienne convivial avec MT, il faut soit l'écrire sous .Net tout de suite, soit avoir besoin de composants qui fonctionnent avec les fenêtres du système Windows, comme KOL (je ne me souviens plus), et la VCL native ne convient pas à ces fins, bien qu'il soit pratique d'en écrire un minimum à la main
Quoi qu'il en soit, en temps voulu, les développeurs de MT ont dit que Sharp est Sharp, et que c'est plus proche du C++, en Delphi pour écrire des kilomètres de begin-end et := , déjà paresseux)))))
hélas, c'est pire, pour rendre un .dll dans Delphi compatible avec MT, il faut soit l'écrire sous .Net tout de suite, soit avoir des composants qui fonctionnent avec les fenêtres du système Windows, comme KOL (je ne me souviens plus), et la VCL native n'est pas adaptée à cette fin, bien qu'il soit pratique d'écrire un minimum à la main...
quoi qu'il en soit, les développeurs de MT ont dit que Sharp est Sharp, et que c'est plus proche de C++, dans Delphi pour écrire des kilomètres de begin-end et := , paresseux)))))
Il y a des années, il y avait même des articles sur cette ressource - "MT est ami avec Delphi" (ou quelque chose comme ça)...
La couche d'interface est la même...
Qui se soucie de savoir dans quelle DLL écrire.
Pascal est probablement difficile à retenir, cela prendrait probablement deux jours, mais peu importe...
ils sont les mêmes, c'est une industrie
quelle différence cela fait-il de savoir dans quel langage les DLL sont écrites ?
Avec l'introduction du support des bibliothèques .Net, la différence apparaît.