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
Eh bien, il y avait un demi-exemple. Il est clair qu'il y a un dossier comme pièce d'une fonction de travail. Où l'interrupteur (boutons) est généré et où nous avons la possibilité d'écrire des réactions aux pressions des boutons.
Oui, c'est un demi-exemple. Je n'ai pas pu aller jusqu'au bout à cause de ce bug avec les positions.
Err quelles autres fonctions sélectionner... il n'est pas nécessaire de faire tout cela. Générer un fichier dans lequel, si j'ai bien compris, les boutons valides sont affectés au commutateur.C'est tout. Arrêt complet. A partir de là, c'est à chacun d'appeler ses réactions à ce bouton. Par exemple pour sauvegarder le fait qu'il a été pressé ou autre. L'environnement pour le retour de la pression, je pense inutile.
Err, quelles autres caractéristiques choisir... Il n'y a pas besoin de tout ça. Générer un fichier dans lequel, si j'ai bien compris, vous attribuez des boutons valides à l'interrupteur. C'est tout. Arrêt complet. A partir de là, c'est à chacun d'appeler ses réactions à ce bouton. Par exemple, pour sauvegarder qu'il a été pressé ou autre. L'environnement pour le retour de la pression, je pense inutile.
Il est préférable de travailler sur la conception
Err, quelles autres caractéristiques choisir... Il n'y a pas besoin de tout ça. Générer un fichier dans lequel, si j'ai bien compris, vous attribuez des boutons valides à l'interrupteur. C'est tout. Arrêt complet. A partir de là, c'est à chacun d'appeler ses réactions à ce bouton. Par exemple pour sauvegarder le fait qu'il a été pressé ou autre. L'environnement pour le retour d'information par clic, je pense que c'est inutile.
Et ici, nous ferions mieux de mettre en œuvre l'environnement par le biais de classes. On appelle aussi le menu des onglets, etc. etc.
Err, quelles autres caractéristiques choisir... Il n'y a pas besoin de tout ça. Générer un fichier dans lequel, si j'ai bien compris, vous attribuez des boutons valides à l'interrupteur. C'est tout. Arrêt complet. A partir de là, c'est à chacun d'appeler ses réactions à ce bouton. Par exemple pour sauvegarder le fait qu'il a été pressé ou autre. Je pense que l'environnement pour le feedback est inutile.
Et l'environnement devrait être mis en œuvre par le biais de classes. Il y a aussi les appels au menu des onglets et ainsi de suite.
Ne brandissons pas l'expression "nous avons besoin de cours" sous le nez de Pierre. Attendons au moins la vidéo, puis nous poserons des questions.
J'ai déjà suggéré à Peter de modifier son "noyau" avec une variante très simple : utiliser des structures. Au diable ces cours, si une personne ne veut pas s'y plonger - c'est son affaire.
Mais l'utilisation de structures ne ferait que faciliter la vie de Peter lui-même.
Ce à quoi le "noyau", c'est-à-dire le tableau global, ressemble maintenant : un tableau multidimensionnel, ou du moins bidimensionnel. La deuxième dimension contient les propriétés d'un certain type de contrôle par des index. Les propriétés sont également accessibles par leur nom, puisque les index sont remplacés par des définitions et que nous obtenons une "pseudo-référence" par nom. En fait, tout est construit sur des définitions, comme ce "langage de balisage" dans le code de Peter.
J'ai déjà suggéré que Peter devrait implémenter une structure, de sorte que le tableau global pourrait être rendu unidimensionnel et que les propriétés pourraient être référencées directement par leur nom. La construction du noyau serait également simplifiée, car il suffirait d'ajouter de nouveaux accessoires à la structure originale et de les désigner par leur nom. Et le code lui-même pourrait être raccourci en supprimant la liste des nombreuses définitions et méthodes pour les utiliser.
D'un côté, ce n'est pas une classe, mais d'un autre côté, cela rendrait la manipulation du tableau global beaucoup plus facile pour Peter. En outre, Peter a déjà une certaine expérience du travail avec une structure similaire : un syndicat.
Mais Peter a sa propre façon de sensei et nous allons attendre le résultat...
Je propose le schéma suivant comme exemple transversal : Créez un formulaire avec trois champs : montant de la transaction, prix SL et prix TP, deux boutons : BUY et SELL.
Créer un Expert Advisor, connecter le GUI comme un inluder. Ajoutez une variable pour l'offre initiale. Lorsqu'il est initialisé, le montant initial de l'offre est transmis au champ approprié dans l'interface graphique.
Créer dans le conseiller expert la fonction "Open Deal". Cette fonction doit être appelée dès qu'un des boutons de l'interface graphique est cliqué.
Dans la fonction elle-même, nous "découvrons" quelle commande a été donnée et demandons également à l'interface graphique quel est le taux actuel et, sur la base de ces données, nous ouvrons la transaction correspondante.
Je propose le schéma suivant comme exemple transversal : Créez un formulaire avec trois champs : montant de la transaction, prix SL et prix TP, deux boutons : BUY et SELL.
Créer un Expert Advisor, connecter le GUI comme un inluder. Ajoutez une variable pour l'offre initiale. Lorsqu'il est initialisé, le montant initial de l'offre est transmis au champ approprié dans l'interface graphique.
Créer dans le conseiller expert la fonction "Open Deal". Cette fonction doit être appelée dès qu'un des boutons de l'interface graphique est cliqué.
Dans la fonction elle-même, nous "découvrons" quelle commande a été donnée et demandons également à l'interface graphique quel est le taux actuel et, sur la base de ces données, nous ouvrons la transaction correspondante.
Vous ne comprenez pas.
Pourquoi, ceci est aussi implémentable par une fonction qui est appelée lorsque le champ est rempli et que la valeur d'entrée est du type modèle... tout. Même si c'est comme la ficelle.... il n'y aura toujours pas de remplissage du champ à grande vitesse