GUI à l'initiative de la foule. Test bêta ouvert. - page 30
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
Pourquoi, il 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 string.... il n'y aura toujours pas de remplissage du champ à grande vitesse
Il ne s'agit pas seulement du champ de saisie. Par exemple, vous devez obtenir la valeur actuelle d'une case à cocher - vérifier si elle est cochée ou non.
Tout cela est également facile grâce à un appel de fonction sur le fait de fixer. et de poursuivre le travail du programmeur.
En ce qui concerne l'environnement, j'aimerais voir un certain ensemble de normes d'appel (sans changer le nom de la fonction - parce que je ne sais pas dans quel morceau de code je peux avoir besoin de telle ou telle fonction) sur toutes sortes de signets et de fenêtres. sélection de la fenêtre de préférence par Select. Ainsi que la sélection du style en changeant de couleur au survol.
C'est-à-dire que vous devez créer un prototype de menu et l'utiliser pour en créer un autre dans le code. Si nous devions utiliser l'environnement...
Ici, les métacitations se brisent parfois dans certains fragments de code.
Ici, il est souhaitable d'ajouter une interface dynamique supplémentaire qui apparaît lorsque l'on clique/surmonte..... Et ce n'est qu'une toute petite partie.
Il ne s'agit pas seulement de la boîte de saisie. Par exemple, vous voulez obtenir la valeur actuelle de la case à cocher - vérifier si la case est cochée ou non.
Mais en plus de cela, il existe une notion telle que lesfonctions de rappel, qui génèrent des événements lorsque quelque chose est modifié. Par exemple, il y a une case à cocher dans le formulaire et nous devons savoir quand son état change. Option 1 : faire des requêtes à l'interface graphique à intervalles réguliers pour obtenir la valeur de cette case, et si la valeur est différente alors la case a changé. Dans ce cas, des ressources sont gaspillées pour l'interrogation périodique constante - ce n'est pas rentable.
Pour éviter de gaspiller des ressources, nous avons inventé des fonctions dites "piggyback" qui nous informent lorsque la valeur d'un contrôle est modifiée. Par exemple, lorsque nous cliquons sur une case à cocher, son état change et dès que l'état change, un événement est généré avec le type, le nom et la valeur du contrôle. Et dans l'abonnement à cet événement sera déjà exécuté le code nécessaire pour attendre que la valeur de la case à cocher change. C'est ce qu'on appelle le modèle d'événement.
tout cela est aussi facile par un appel de fonction sur le fait de fixer. et ensuite le travail du programmeur.
En ce qui concerne l'environnement, j'aimerais voir un certain nombre de normes pour l'appel (sans changer le nom de la fonction, car je ne sais pas dans quel morceau de code je peux avoir besoin de telle ou telle fonction) sur toutes sortes d'onglets et de fenêtres. Ainsi que la sélection du style en changeant de couleur au survol.
C'est-à-dire que vous devez créer un prototype de menu et l'utiliser pour en créer un autre. Si nous devions utiliser l'environnement...
Ici, les métacitations se brisent parfois dans certains fragments de code.
ici, il est souhaitable de modifier l'interface supplémentaire qui apparaît lorsque vous cliquez/surmontez..... Et c'est une toute petite partie.
Il existe également une notion defonctions de rappel, qui génèrent des événements lorsque quelque chose change. Par exemple, il y a une case à cocher dans le formulaire et nous devons savoir quand son état change. Option 1 : faire des requêtes à l'interface graphique à intervalles réguliers pour obtenir la valeur de cette case, et si la valeur est différente alors la case a changé. Dans ce cas, des ressources sont gaspillées pour l'interrogation périodique constante - ce n'est pas rentable.
Pour éviter de gaspiller des ressources, nous avons inventé des fonctions dites "piggyback" qui donnent une notification lorsque la valeur du contrôle a changé. Par exemple, lorsque vous cliquez sur une case à cocher, son état change. Dès que l'état a changé, l'événement avec le type, le nom et la valeur du contrôle est généré. Et dans l'abonnement à cet événement sera déjà exécuté le code nécessaire pour attendre que la valeur de la case à cocher change. C'est ce qu'on appelle le modèle d'événement.
Eh bien, Alexey, vous parlez d'une interface graphique externe, interrogée par l'EA via une minuterie, à partir d'une ancienne mémoire. À l'époque, il fallait des rappels. Maintenant, tout se passe au sein d'une seule EA et au lieu de l'interface graphique externe, il y a une interface interne. Le sien.
Peter, en fait, les colbecs ne sont pas un "vieux souvenir", mais une pratique courante pour toute interaction, pas nécessairement liée à l'interface graphique, qu'elle soit externe ou interne. Et peu importe OÙ cela se produit, l'essentiel est COMMENT cela se produit. Colbeck n'est pas un timer !
J'attends la vidéo...
Peter, en fait, les colbikes ne sont pas un "vieux souvenir" mais une pratique courante de toute interaction, qui ne doit pas nécessairement être liée à l'interface graphique, qu'elle soit externe ou interne. Et peu importe où cela se passe, l'essentiel est comment cela se passe.
J'attends la vidéo...
Eh bien, Alexey, vous parlez d'une interface graphique externe interrogée par EA via une minuterie, de mémoire ancienne. À l'époque, nous avions besoin de rappels. Maintenant, tout se passe à l'intérieur d'un seul conseiller expert et au lieu de l'interface graphique externe, il y a une interface interne. Le sien.
Il est plus facile de se souvenir de ses propres variables que d'apprendre celles de quelqu'un d'autre.
Le code en général devrait avoir un minimum de variables globales, toutes mises en œuvre en passant des morceaux de mémoire et en traitant plusieurs valeurs à la fois. Il est logique que ..... .... .... HH a essayé de couper les mots liés directement aux objets.
En général, il est plus facile d'utiliser des colobacons réguliers.
Il est plus facile de se souvenir de ses propres variables que d'apprendre celles de quelqu'un d'autre.
En général, le code devrait avoir un minimum de variables globales, toutes mises en œuvre en passant des morceaux de mémoire et en traitant plusieurs valeurs à la fois. Il est logique que ..... .... .... HH a essayé de couper les mots liés directement aux objets.
En général, il est plus facile d'utiliser des colliers de serrage ordinaires.
PS : vous avez encore beaucoup de travail de conception à faire ici.
Je suis d'accord. Seulement à l'intérieur d'une EA, nous n'en aurons pas besoin.
Hmmm... alors une question simple : comment savoir si l'état de la case à cocher a changé ?