Réaliser un projet de crowdsourcing sur Canvas - page 34
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
L'application est séparée, l'interface graphique est séparée.
Mais le traitement des données déduites dans l'interface graphique est de toute façon effectué de manière synchrone.
Par exemple, l'application envoie 10000 éléments au GUI et le GUI traite tous ces éléments de manière séquentielle.
C'est là le problème. Il est nécessaire de paralléliser le traitement des éléments entrants et leur sortie dans l'interface graphique. Base, texte, icône.
D'autant plus qu'il y a trois cycles par cellule.
C'est vrai. Mais, dans les circonstances actuelles, le traitement en parallèle est peu pratique. Nous devons connecter plus d'AE ou de services. Il s'agira d'une mise en œuvre lourde et décousue.
Il existe une méthode basée sur les diagrammes d'objets. Je n'y suis pas entré, mais cela peut m'aider à créer plusieurs fils. Cela a quelque chose à voir avec les modèles...
Je comprends, l'application est séparée, l'interface graphique est séparée.
Mais le traitement des données de sortie dans l'interface graphique est de toute façon effectué de manière synchrone.
Ainsi, par exemple, l'application envoie 10000 éléments au GUI et le GUI traite tous ces éléments de manière séquentielle.
C'est là le problème. Il est nécessaire de paralléliser le traitement des éléments entrants et leur sortie dans l'interface graphique. Base, texte, icône.
D'autant plus qu'il y a trois cycles par cellule.
Il est peu probable que cela fonctionne. Même le winda traite l'interface dans un seul fil. Sinon, les fenêtres et les contrôles ne seront pas prioritaires. Seuls l'interface graphique elle-même et le traitement des différentes données peuvent être divisés en threads. De facto, même la modification des données dans les contrôles n'est pas autorisée depuis un autre thread. Un dialogue doit toujours être cohérent, de sorte que tout rendu et toute réaction d'un dialogue sont strictement dans un seul thread, c'est-à-dire que tout se passe de manière synchrone.
Toutes les opérations dans MT sont strictement synchrones et cela ne peut pas vraiment être changé à moins que les développeurs ajoutent des threads à l'application.
Il est assez surprenant que les développeurs essaient d'étendre les fonctionnalités de MT en termes de travail avec des bases de données, avec python, avec sharpe... mais ils proposent de faire tout cela dans le même fil...
C'est juste incroyable.
Je suis d'accord avec la surprise.
La seule solution est de voir une dll avec des fonctions asynchrones pour vos applications.
Mais ces applications ne peuvent même pas être placées dans la kodobase, car la dll n'est pas autorisée.
Il est peu probable que cela fonctionne. Même l'interface Windows est gérée par un seul thread. Sinon, les fenêtres et les commandes ne seront pas prioritaires. Seuls l'interface graphique elle-même et le traitement des différentes données peuvent être divisés en threads. De facto, même la modification des données dans les contrôles n'est pas autorisée depuis un autre thread. Un dialogue doit toujours être cohérent, donc tout rendu et toute réaction d'un dialogue sont strictement dans un seul fil, c'est-à-dire que tout se passe de manière synchrone.
Il me semble que tout va s'arranger, il faut juste réfléchir à l'avance à la priorité du traitement asynchrone des données.
C'est-à-dire construire un schéma de traitement asynchrone, avec un traitement synchrone.
Je suis d'accord, avec surprise.
La seule solution est de voir une dll avec des fonctions asynchrones dans vos applications.
Mais ces applications ne peuvent même pas être placées dans une kodobase car la dll n'est pas autorisée.
En fait, il n'y a pas encore de réel besoin de paralléliser le traitement des événements de l'interface graphique. Si les tableaux de 1000 cellules fonctionnent relativement vite, même sur MT4, il y a plus qu'assez de vitesse pour le reste des événements. Dans ma pratique, il n'y a pas de ralentissement. Si vous avez besoin d'une animation ultra-rapide, vous pouvez connecter OpenCL. MT5 tire parfaitement l'interface graphique ordinaire. Aucun problème. Je viens de montrer qu'il faut être très attentif au redécoupage de la toile.
Si le conseiller expert lui-même comprend des calculs lourds, la fréquence de sortie des données dans l'interface graphique peut être réduite. Le redécoupage d'une grande fenêtre peut atteindre 100 ms mais il est généralement bien inférieur. Ainsi, un délai de 100 ms sur l'interface graphique ne peut être perceptible qu'avec des calculs d'EA très lourds.
Je suis d'accord, avec surprise.
La seule solution est de voir une dll avec des fonctions asynchrones pour vos applications.
Mais ces applications ne peuvent même pas être placées dans une kodobase car la dll est interdite.
Beaucoup de choses peuvent être faites au niveau de la DLL.
C'est tout ce que MT n'est pas conçu pour et peut+doit+y faire :-)
Vous ne pouvez pas contrôler le dll, c'est pourquoi il n'est pas sur le marché. Vous pouvez trouver des dlls dans kodobase, d'ailleurs. Peut-être qu'ils l'ont interdit maintenant pour une raison quelconque.
PS : à propos, question curieuse - les DLL peuvent être signées avec la clé du développeur. Il est possible d'autoriser de telles DLL sur le marché et sur kodobeise également, mais elles seront liées à l'infrastructure de Microsoft. Quelqu'un ici est prêt à acheter une telle licence pour Visual C ?Je suis d'accord, avec surprise.
La seule solution est de voir une dll avec des fonctions asynchrones pour vos applications.
Mais ces applications ne peuvent même pas être placées dans une kodobase car la dll est interdite.
Oui, c'est le principal problème ! Le même marché interdit l'utilisation de dlls, nous devons donc réinventer la roue. Ok, si quelqu'un pense que l'interface graphique n'est pas nécessaire, mais n'importe quel long calcul complexe dans n'importe quel cas dans un seul fil ne fonctionnera pas, tout se bloquera ! Il faut donc le faire dans un dll... ce qui est interdit sur le marché...
Et ainsi de suite. Pour cette raison, je dois dessiner et tout résoudre avec des méthodes mql.
En fait, la séparation de l'interface graphique et de la logique en threads est, bien sûr, déjà possible. Ici, les gars ont déjà discuté de la question du parallélisme https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
Par conséquent, le formulaire lui-même pourrait être laissé dans le fil d'exécution principal, comme c'est le cas dans winnda, tandis que tous les calculs supplémentaires pourraient être déplacés vers une exécution en "arrière-plan". C'est comme ça que fonctionnent Windows, Linux et Android.
Vous pouvez faire tellement de choses au niveau de la DLL.
C'est ce à quoi MT ne sert pas et peut+doit+faire :-)
Vous ne pouvez pas contrôler le dll, c'est pourquoi il n'est pas sur le marché. Nous avons des dlls dans kodobase, d'ailleurs. Peut-être qu'ils l'ont interdit maintenant à cause d'une certaine agitation.
PS : à propos, question curieuse - les DLL peuvent être signées avec la clé du développeur. Il est possible d'autoriser de telles DLL sur le Marketplace et dans Kodobeise également, mais cela sera lié à l'infrastructure de Microsoft. Quelqu'un ici est prêt à acheter une telle licence pour Visual C ?Oui, vous ne pouvez pas contrôler la dll, mais vous pourriez autoriser les mêmes bibliothèques de vent...
N'allez pas jusque-là : même dans le cadre d'une bibliothèque standard, il existe des fonctions permettant d'accéder à winAPI ! Mais quel est l'intérêt ? Après tout, vous ne pouvez pas le mettre sur la place du marché....
Ok, avec toute cette discussion, nous sommes entrés dans une autre inondation.
Il y a beaucoup de choses que vous pouvez faire au niveau de la DLL.
C'est ce à quoi MT n'est pas destiné et qui peut+doit+être fait là :-)
Vous ne pouvez pas contrôler le dll, c'est pourquoi il n'est pas sur le marché. Et dans kodobase, au fait, vous pouvez trouver des dlls. Peut-être qu'ils l'ont interdit pour une raison quelconque.
PS : à propos, question curieuse - les DLL peuvent être signées avec la clé du développeur. Il est possible d'autoriser de telles DLL sur le Marketplace et dans Kodobeise également, mais cela sera lié à l'infrastructure de Microsoft. Quelqu'un ici est prêt à acheter une telle licence pour Visual C ?Pourquoi se lier à l'infrastructure Microsoft ?
Je pense qu'absolument n'importe quelle clé peut être utilisée pour signer une dll, tant qu'elle est contrôlée par MQ.
Il s'ensuit que ces clés doivent être émises par MQ, et contrôlent la quantité de hachage de l'application.
Pourquoi devraient-ils se lier à l'infrastructure de Microsoft ?
Je pense que n'importe quelle clé peut être utilisée pour signer une dll, tant qu'elle est contrôlée par MQ.
Il s'ensuit que ces clés doivent être émises par MQ, et contrôlent la somme de hachage de l'application.
mais parce que microsoft est le patron dans cette fourmilière :-)
Pourquoi pensez-vous que les gens perdent leurs données de connexion lors de la mise à niveau et de l'activation de produits sur des vinyles piratés ?