Programmation asynchrone et multithread dans MQL - page 25
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
J'ai commencé à relire le sujet et Igor avait déjà écrit à ce sujet.
C'est ce que j'essayais de dire, Yuri, que nous devons allouer de la mémoire et enregistrer le flux.
Igor dit que vous devez allouer et enregistrer, alors que vous dites que vous n'avez rien à faire.
C'est pour ça que j'ai la tête qui tourne. Le résultat est une impasse.
Igor a étudié à l'université en tant que spécialiste, et il devrait en savoir plus que nous autres autodidactes.
Dès le début, j'étais enclin à la même idée - que la mémoire doit être allouée et initialisée.
L'initialisation et l'allocation de la mémoire sont la clé d'un codage correct, car elles ne doivent pas couler et ne doivent pas être des déchets.
Je demande donc à Igor de m'expliquer comment le faire en C++ ?
Pas en mots, avec un exemple, je ne comprends rien ;))
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; }J'ai commencé à relire le sujet et Igor a déjà écrit à ce sujet.
C'est ce que j'essayais de dire, Yuri, que nous devrions allouer de la mémoire et enregistrer le flux.
J'ai commencé à relire le fil et Igor avait déjà écrit à ce sujet.
J'étais initialement enclin à la même idée : allouer de la mémoire et initialiser.
L'initialisation et l'allocation de mémoire sont la clé d'un codage correct, car elles ne doivent pas dégouliner et être exemptes de déchets.
Je demande donc à Igor de m'expliquer comment le faire en C++ ?
Vous poussez magistralement ce fil de discussion vers le haut de la discussion, en essayant d'attirer de plus en plus de participants à votre problème )))).
Ne sortez pas la correspondance de son contexte :
- Je l'ai écrit dans le contexte que si vous voulez comprendre comment fonctionne WinAPI, vous pouvez utiliser des exemples prêts à l'emploi sur l'écriture de dll = plus de 20 articles sur cette ressource.
- Je l'ai écrit dans un contexte où vous pouvez obtenir des appels WinAPI purs, en remplaçant les plugins que les programmeurs de votre système ont déjà écrits pour vous.
....
le but de la correspondance : commencer à lire et à faire quelque chose, et non pas écrire et écrire.... Vous comprendrez beaucoup, vous comprendrez ce qui et comment fonctionne dans Windows, mais cette connaissance ne sera pas en demande, devous comme du programmeur d'application que le travail mécanique - choisi le type de projet, ajouté votre code, compilé = obtenu le résultat - tout le travail pour vous ont fait des centaines ou des milliers de programmeurs de système. Toute modification des modèles et des fichiers d'inclusion doit avoir un sens - si vous ne le savez pas, sous couvert de "pourquoi tant de code, cela fonctionne déjà !". - Vous obtiendrez un bogue non reproductible et/ou un manque de compatibilité (portabilité) avec l'OS/PC.
Le poste est destiné aux créateurs. Éloignez les trolls. Pour les interfaces graphiques, il est bon de placer le OnChartEvent dans un thread séparé.
Pourquoi casser le modèle que les développeurs ont créé ? - Le modèle de programme MQL est simple et clair, il y a des événements - il y a des points d'entrée qui traitent ces événements (OnTick(), OnInit()....OnChartEvent()).
il est possible d'obtenir l'état de l'environnement de négociation à partir de n'importe quel programme MQL (même les indicateurs peuvent voir le bénéfice d'un ordre ouvert, etc.) et il est possible de combiner Conseiller expert + script, Conseiller expert + indicateur utilisateur sur le même graphique - vous obtenez une exécution asynchrone des programmes MQL, l'EA négocie, l'indicateur affiche la visualisation graphique - si la performancedu flux desindicateurs utilisateur n'est pas suffisante (ils travaillent dans un seul thread), alors bien sûr c'est un problème - vous devez utiliser 2 EA sur 2 graphiques et organiser leur interaction
Encore une fois - il y a une tâche spécifique, il y a une mise en œuvre, j'ai demandé à plusieurs reprises pourquoi cette fonctionnalité est nécessaire, mais jusqu'à présent il n'y a pas de réponse - seulement un raisonnement spatial sur la visualisation 3D..... et il n'est pas question de savoir où obtenir du DirectX pour travailler avec la 3D ;)
imho, ça marche ! )))
Pourquoi casser le modèle que les développeurs ont créé ? - Le modèle de programme MQL est simple et clair, il y a des événements - il y a des points d'entrée qui traitent ces événements (OnTick(), OnInit()....OnChartEvent()).
il est possible d'obtenir l'état de l'environnement de négociation à partir de n'importe quel programme MQL (même les indicateurs peuvent voir le bénéfice d'un ordre ouvert, etc.) et il est possible de combiner Conseiller expert + script, Conseiller expert + indicateur utilisateur sur le même graphique - vous obtenez une exécution asynchrone des programmes MQL, l'EA négocie, l'indicateur affiche la visualisation graphique - si la performancedu flux desindicateurs utilisateur n'est pas suffisante (ils travaillent dans un seul thread), alors bien sûr c'est un problème - vous devez utiliser 2 EA sur 2 graphiques et organiser leur interaction
Encore une fois - il y a une tâche spécifique, il y a une mise en œuvre, j'ai demandé à plusieurs reprises pourquoi cette fonctionnalité est nécessaire, mais jusqu'à présent il n'y a pas de réponse - seulement un raisonnement spatial sur la visualisation 3D..... et il n'y a pas de discussion sur l'endroit où obtenir du DirectX pour travailler avec la 3D ;)
imho, ça marche ! )))
Regardez. Il y a un bouton. Vous cliquez dessus. Le OnChartEvent est placé dans la file d'attente. Mais dans cette file d'attente il y a déjà OnTick, et à sa suite il y a OnTime, et dans ceux-ci il y a CopyRate pour tous les outils, ce qui, pendant une seconde, bloque et boucle pour une putain de tonne d'itérations. Par conséquent, si le bouton, par exemple, doit ouvrir une fenêtre de dialogue, nous obtenons une interface lente. Pas critique, bien sûr, mais pas gentil.
L'interface graphique doit tourner dans l'EA principale et tout le reste dans une EA séparée. Cet EA esclave séparé est placé surOBJ_CHART invisible et interagit avec le chemin principal EventSendCustom().
Il obtient quelque chose comme un multithreading. Je l'ai mis en œuvre de cette façon.
Regardez. Il y a un bouton. Vous cliquez dessus. OnChartEvent est placé dans la file d'attente. Mais dans cette file d'attente il y a déjà OnTick, et à sa suite il y a OnTime, et dans ceux-ci il y a CopyRate pour tous les outils, qui, pendant une seconde, bloque et boucle pour un tas de putains d'itérations. Par conséquent, si le bouton, par exemple, doit ouvrir une fenêtre de dialogue, nous obtenons une interface lente. Pas critique, bien sûr, mais pas gentil.
Je ne connais pas OnChartEvent OnTick et OnTime, mais les développeurs ont écrit que si EA était occupé et n'a pas traité l'événement, cet événement ne crée pas de file d'attente, c'est-à-dire qu'il s'agira juste d'un saut de tic ou de minuterie ( OnChartEvent - je ne sais pas, je n'ai pas vérifié)
La logique des développeurs est simple ici, chaque événement est une action spécifique du Conseiller Expert, mais c'est cet événement que je connais avec certitude et que j'ai vérifié plus d'une fois (je travaille plus en théorie dans MT5, je ne sais pas comment ONTick fonctionne physiquement) :
En ce qui concerne MT4, je dirai sans ambiguïté que toutes les opérations commerciales doivent être effectuées uniquement par le biais du tick entrant, sinon dans 9 cas sur 10, vous recevrez un refus du serveur de traiter l'opération commerciale,
c'est-à-dire qu'une interface avec le bouton BUY a été implémentée - selon notre idée, vous appuyez sur BUY et envoyez immédiatement un ordre, mais cela ne fonctionnera pas directement, vous devez vous souvenir de la commande de l'utilisateur (idéalement, bloquer le bouton pour qu'il n'yak pas)) et à l'arrivée du tick, dans OnTick() - envoyer un ordre au serveur - cela fonctionnera dans 99% des cas, c'est-à-dire qu'un tick est arrivé - vous pouvez effectuer une demande de transaction (pas depuis n'importe où dans MQL)
Et si nous introduisons OnChartEvent dans un flux asynchrone, nous obtiendrons des verrouillages mutuels du code exécuté ? - Par exemple, les statistiques sur les transactions sont obtenues en appuyant sur le bouton dans OnChartEvent , et la même fonction (dernière transaction perdante) est utilisée dans OnTick - il y aura quelque chose de fou ici ! - imho, on ne peut pas tout réparer !
L'interface graphique doit tourner dans l'EA principale et tout le reste dans une EA séparée. Cet EA esclave séparé est placé surOBJ_CHART invisible et interagit avec le chemin principal EventSendCustom().
Il obtient quelque chose comme un multithreading. Je l'ai mis en œuvre de cette façon.
Je ne connais pas OnChartEvent OnTick et OnTime, mais les développeurs ont écrit que si EA était occupé et n'a pas traité l'événement, cet événement ne crée pas de file d'attente, c'est-à-dire qu'il s'agira juste d'un saut de tic ou de minuterie ( OnChartEvent - je ne sais pas, je n'ai pas vérifié)
La logique des développeurs est simple ici, chaque événement est une action spécifique du Conseiller Expert, mais c'est cet événement que je connais avec certitude et que j'ai vérifié plus d'une fois (je travaille plus en théorie dans MT5, je ne sais pas comment ONTick fonctionne physiquement) :
Pour ce qui est de MT4, je dirai sans ambiguïté que toutes les opérations commerciales doivent être effectuées uniquement par le biais du tick entrant, sinon dans 9 cas sur 10, vous recevrez un refus du serveur de traiter l'opération commerciale,
c'est-à-dire que j'ai créé une interface avec le bouton BUY - selon mon idée, vous appuyez sur BUY et envoyez immédiatement un ordre, mais cela ne fonctionnera pas directement, vous devez mémoriser la commande de l'utilisateur (idéalement, bloquer le bouton pour qu'il ne fasse pas de yak)) et à l'arrivée d'un tick dans OnTick () - envoyer un ordre au serveur - cela fonctionnera dans 99% des cas, c'est-à-dire qu'un tick est arrivé - vous pouvez effectuer une demande de transaction (pas depuis n'importe où dans MQL)
Et si nous introduisons OnChartEvent dans un flux asynchrone, nous obtiendrons des verrouillages mutuels du code exécuté ? - Par exemple, les statistiques sur les transactions sont obtenues en appuyant sur le bouton dans OnChartEvent , et la même fonction (dernière transaction perdante) est utilisée dans OnTick - ce serait grave ! - imho, on ne peut pas tout réparer !