Création d'une interface graphique pour les MQL en mode graphique. - page 13
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
Maxim, en quoi cette solution est-elle meilleure ? Après tout, pour vérifier l'état d'un drapeau, il faut aussi le vérifier périodiquement dans MQL. Il s'avère donc que partout où vous regardez, vous devez surveiller constamment les changements d'état de quelque chose pour comprendre qu'il est temps de ramasser les données. Et ce fragment peut être stocké dans la dll elle-même et vérifié là - c'est ce que je fais. Dans votre exemple, vous avez un appel implicite à la dll pour retourner l'état du drapeau.
La vérification du drapeau est une opération très rapide. Je veux dire le plus rapide du tout :-)
Et il n'y a pas d'appels implicites dans cet exemple :
InitDLL reçoit int *flags en entrée, le stocke quelque part, génère une trace qui compte quelque chose et à la fin fait atomic_inc(flags).
Le conseiller doit seulement vérifier les drapeaux[0].
La vérification du drapeau est une opération très rapide. C'est-à-dire qu'il est le plus rapide du tout :-)
Et il n'y a pas d'appels implicites dans cet exemple :
InitDLL reçoit int *flags en entrée, le stocke quelque part, génère une trace qui compte quelque chose et fait atomic_inc(flags) à la fin.
Le conseiller doit seulement vérifier les drapeaux[0].
Mais vous ne pouvez pas ne rien faire en vérifiant simplement le drapeau - une synchronisation inter-thread est nécessaire, des barrières, atomique ou mutex laquelle prendre, bien sûr, pour pas tous les CPU.
Exactement pour vérifier. C'est le point essentiel. Et je suggère d'avertir l'outil que la "tâche" a été accomplie. En d'autres termes, vous ne devez pas consacrer des ressources constantes à la vérification. La notification est arrivée - vous avez reçu les données.
La vérification du drapeau est une opération très rapide. C'est-à-dire qu'il est le plus rapide du tout :-)
Et il n'y a pas d'appels implicites dans cet exemple :
InitDLL reçoit int *flags en entrée, le stocke quelque part, génère une trace qui compte quelque chose et à la fin fait atomic_inc(flags).
L'EA doit seulement vérifier les drapeaux[0].
Nous utiliserons ce que nous avons et attendrons que les développeurs ajoutent la fonction de rappel.
Je veux revenir à la question de l'interface graphique. Peu importe sur quoi il est dessiné. Par exemple, je le fais en Sharp, vous le faites en Tcl.
Tant que le formulaire existe par lui-même, ce n'est pas un problème du tout. Mais j'aimerais vraiment que les formulaires ne volent pas tout seuls, mais qu'ils soient liés aux tableaux appropriés.
Lorsque vous définissez le parent du formulaire créé, il est placé sur le graphique requis. Mais il y a un problème de "fusion" de la fenêtre avec le graphique et le graphique ne fait que dessiner la forme "collée".
Je suggère d'essayer de résoudre ce problème pour l'instant, car il reste en dehors du champ d'action des développeurs de MT.
Avez-vous essayé d'attacher votre GUI aux graphiques ?
Mais vous ne pouvez pas vous contenter de vérifier les drapeaux, vous avez besoin d'une synchronisation inter-fil, de barrières, d'atomique ou de mutex, ce qui n'est pas pertinent pour tous les CPU, bien sûr.
Et comment sont implémentées toutes sortes de mutex ? Tout ça en vérifiant et en mettant des drapeaux, pour autant que je sache. Vous devez vérifier un drapeau quelque part dans le fil µl de toute façon.
Tout à fait vrai. Mais que cela se passe à un niveau très bas, celui de l'application, comme, par exemple, cela fonctionne avec OnChartEvent. C'est-à-dire que maintenant nous le programmons explicitement (contrôles), mais tout cela pourrait être transféré au niveau de l'application, comme Renat l'a dit (il a suggéré quelques variantes).
Je suis en bas :-) donner - pouvez-vous l'envoyer à MS
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
s'il y a autre chose, je pourrais le trouver.
Merci, j'ai réussi, j'ai eu une livre !
Merci, j'ai réussi, j'ai eu une livre !
donc c'est plus rentable que scalper ! prêt à les vendre au détail pour un centime, vous les vendez en gros pour 1$/tens. la seule limite est la vitesse de transmission :-) quelques kilobytes de GUIDs par seconde
Tentant comme l'enfer. C'est ainsi que nous allons conquérir le marché des GUID d'occasion ! Et devenir un monopole, créer une frénésie artificielle comme avec le bitcoin et devenir riche !
Nous utiliserons ce que nous avons et attendrons que les développeurs ajoutent la fonction de rappel.
Je veux revenir à la question de l'interface graphique. Peu importe sur quoi il est dessiné. Par exemple, je le fais en Sharp, vous le faites en Tcl.
Tant que le formulaire existe par lui-même, ce n'est pas un problème du tout. Maisj'aimeraisvraiment que les formulaires ne volent pas tout seuls, mais qu'ils soient liés aux tableaux appropriés.
Lorsque vous définissez le parent du formulaire créé, il est placé dans le tableau requis. Mais il y a un problème de "fusion" de la fenêtre avec le graphique et le graphique ne fait que dessiner la forme "collée".
Je suggère d'essayer de résoudre ce problème pour l'instant, car il reste en dehors du champ d'action des développeurs de MT.
Avez-vous essayé d'attacher votre GUI aux graphiques ?
Je n'ai pas besoin d'enchaîner les formulaires aux tableaux.
Il existe des graphiques opérationnels qui sont directement liés au graphique (toutes sortes de lignes, légendes, inscriptions, etc.), ce qui est naturellement fait par les outils de TA.
Mais il existe des interfaces graphiques de gestion - paramètres, rapports, statistiques. Ils sont assez gros et c'est un crime contre l'utilisateur :-)
Il suffit de placer le formulaire au-dessus du graphique. Vous devrez retirer le formulaire du gestionnaire de fenêtres et suivre les modifications de la géométrie du graphique et du focus.
La mise à jour/ le placement d'un formulaire - mettez RectLabel sur le graphique et dans le chart-events pour suivre le changement de codinates. Lorsqu'il change - mettez sa forme strictement en haut :-) Il faut un peu de tambourin quand on change d'onglet, minimiser la fenêtre, pour cacher son formulaire à tempsUn tel "coucher de soleil à la main" :-) Au moins, vous n'entrerez pas dans les entrailles de MetaTrader et n'imposerez pas de nouveaux frissons et crochets sur ses fenêtres - c'est-à-dire que vous vous comporterez décemment.
Toute interface graphique appelée à partir d'une DLL présente la caractéristique la plus désagréable - les conseillers-experts/indicateurs qui l'appellent redémarrent périodiquement au moindre éternuement. Ce qui conduit à la réouverture des formulaires et à des cascades de grossièretés...
Peut-être les "services" annoncés depuis longtemps (ou quel que soit le nom qu'on leur donne) seront-ils dépourvus de cet inconvénient.
Vous n'avez rien expliqué du tout. Comment faites-vous pour transférer les données de MT* vers le panneau Sharpe ?
J'ai procédé à un retour d'information par le biais de la cartographie de la mémoire avec des sondages chronométrés. Le panneau ne transmettait que des paramètres différents et des résultats de calcul lents