Mon approche. Le noyau est le moteur. - page 122
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
Je le ferai.
Il sera prêt après-demain.
C'est génial. Je vais attendre.
J'ai lu et lu ce sujet... Je me suis demandé quel était le public cible de Peter. À qui vendra-t-il son interface graphique ? La question n'est pas oiseuse...
Je viens de réaliser - ceux qui tradent manuellement selon les méthodes de Gann. C'est là que la précision des proportions géométriques et la beauté sont vraiment nécessaires.
Il est donc probable que l'on trouve des acheteurs - mais les méthodes de Gann ne sont pas si simples qu'elles puissent être représentées graphiquement si facilement :))
Super. Je vais attendre.
J'ai été retenu. Aujourd'hui - demain, la table sera prête.
(Un tableau dynamique offre de nombreuses possibilités intéressantes. Il a fallu du temps pour les mettre en œuvre).
Enfin, le tableau dynamique est terminé. Je dois dire que ce n'était pas facile. Il s'avère qu'il y a beaucoup de nuances.
De plus, ce tableau est dynamique "conditionnellement". C'est-à-dire que le nombre maximal de rangées est prédéterminé. Il n'était pas encore possible de rendre "absolument" dynamique.
Ce tableau comporte 20 lignes possibles. Ainsi, il peut afficher 20 positions ouvertes. Nous pourrions en faire plus, mais c'est juste une démonstration pour l'instant.
Cliquez pour voir.
//---------------------------------------------
Voici les fichiers de connexion (mis dans l'inline), le moteur (dans le dossier indicators), et le test.advisor (dans le dossier experts) :
De plus, je ne sais pas comment vérifier si un ordre est fermé ou encore ouvert (j'ai oublié). Pour cette raison, je n'ai pas été en mesure de fermer automatiquement une ligne lorsqu'un ordre stop ou un ordre d'achat est déclenché.
Qui sait, donnez votre avis.
1. un panneau configurable automatiquement serait idéal.
3. j'ai esquissé ma vision en gros
4. un simple bouton fera l'affaire.
Demain, je vous donnerai la vue finale du panneau avec un tableau des commandes.
Immédiatement après, j'implémenterai l'interaction avec le panneau dans le testeur.
Super. Je vais attendre.
La base de la table dynamique est prête. Vous pouvez maintenant le développer.
Vous pourriez essayer de mettre d'autres éléments dans les rangées. Champs de saisie, listes déroulantes...
Je ne l'ai pas encore essayé, mais en théorie, ça devrait marcher.
Enfin, le tableau dynamique est terminé. Je dois dire que ce n'était pas facile. Il s'avère qu'il y a beaucoup de nuances.
De plus, ce tableau est dynamique "conditionnellement". C'est-à-dire que le nombre maximal de rangées est prédéterminé. Il n'était pas encore possible de rendre "absolument" dynamique.
Ce tableau comporte 20 lignes possibles. Ainsi, il peut afficher 20 positions ouvertes. Nous pourrions en faire plus, mais c'est juste une démonstration pour le moment.
Cliquez pour voir.
//---------------------------------------------
Voici les fichiers de connexion (mis dans l'inline), le moteur (dans le dossier indicators), et le test.advisor (dans le dossier experts) :
La tâche suivante consiste à refaire la communication entre l'EA et le moteur. Au lieu de EventChartCustom(), la connexion sera partiellement implémentée par la description d'objets МТ, et partiellement, par des ressources.
Le problème est que j'ai remarqué, en créant l'animation, que le transfert de données par le biais des ressources sollicite beaucoup le processeur. C'est-à-dire qu'il s'agit d'une méthode non seulement plus lente, mais aussi plus consommatrice de ressources.
Elle a ses avantages, à savoir la simplicité et la commodité. De plus, cette méthode est adaptée au transfert de grandes quantités de données. Mais, lorsqu'on met en œuvre la communication par le biais de ressources, le processeur sera encore plus sollicité lors du processus de test. Après tout, le testeur lui-même charge le processeur jusqu'à 40%. Et cela s'ajoutera à la charge due à la sauvegarde et à la lecture constantes de la ressource.
Je pense qu'en transmettant des informations par le biais de la description des objets MT, il n'y aura pas de charge supplémentaire sur le processeur. Bien que ce ne soit qu'une supposition.
En général, les ressources seront utilisées lors du passage de tableaux de données à traiter par le moteur (données pour les graphiques, l'animation), et les objets МТ porteront les valeurs des paramètres dans leurs descriptions.
ZS. Il est possible que le processeur soit surchargé par le redécoupage, cependant. C'est-à-dire, dessiner à l'intérieur d'un tableau de pixels. En d'autres termes, l'initialisation constante du tableau avec des valeurs se produisant à une fréquence de timer élevée (16ms).