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
Exemple de code simple :
Tout ce qui est commencé doit être terminé. Même si personne n'en a besoin. C'est le principe.
Vous en avez besoin. Si l'interface peut être non seulement dessinée, mais utilisée. Je l'espère.
Besoin. Si l'interface peut non seulement être dessinée, mais aussi utilisée. Espérons-le.
Absolument. C'est ce sur quoi je travaille.
La reproduction de cette branche dans plusieurs langues est une épreuve difficile, bien sûr, pour les non-russophones. Pour l'avenir, puis-je vous poser quelques questions ? Étant donné que votre interface graphique est créée sans utiliser de classes, plusieurs incertitudes surgissent en même temps. Après tout, quelles devraient être les exigences de l'interface graphique en tant que produit ? Il s'agit de la commodité et de l'intuitivité de la création d'une interface graphique, ainsi que de son utilisation pratique dans le processus de travail. À cet égard, voici les questions à poser :
Question 1
Quel mécanisme existe-t-il pour qu'un programmeur puisse gérer les événements dans le cadre de votre interface graphique ? Par exemple, dans mes interfaces graphiques, lors de la création d'uncontrôle, j'ajoute un pointeur vers une fonction de gestion lorsqu'un événement de changement se produit sur ce contrôle. Exemple de code :
Question 2
Comment un programmeur peut-il accéder à l'état d'un élément particulier de l'interface graphique ? Par exemple, dans mon interface graphique, je peux obtenir l'état d'une case à cocher (bool) comme ceci : ... mais j'utilise des classes imbriquées.
Mais j'utilise des classes imbriquées. Comment faites-vous ?
Question 2
Comment un programmeur peut-il accéder à l'état d'un élément particulier de l'interface graphique ? Par exemple, dans mon interface graphique, je peux obtenir l'état d'une case à cocher (bool) comme suit : mais j'utilise des classes imbriquées. Comment procédez-vous ?
Nicholas Bonjour !
Je vais répondre dans l'ordre :
1. L'utilisateur n'interagit PAS (du tout) avec mon code. Ce n'est pas nécessaire. Vous comprendrez plus loin pourquoi. L'utilisateur n'a besoin QUE du langage de balisage. (J'ai déjà insisté sur ce point à plusieurs reprises, mais les programmeurs me posent toujours cette question récurrente. ) La raison en est que l'utilisateur "initialise" le tableau uniquement à l'aide de mots-clés du langage qui sont définis par des "defines" dans le code du constructeur. L'interprète (l'indicateur) envoie un tableau avec le code de balisage (celui que j'ai montré ci-dessus) au constructeur (qui est l'EA sur le même graphique) et le constructeur lit le tableau et construit l'interface graphique. Le code du langage de balisage est une instruction pour le constructeur. Il exécute la construction (dessin, initialisation des paramètres des éléments, réglages, etc.
2. Le mécanisme est simple. Après avoir fini d'éditer l'interface, l'utilisateur appelle le menu contextuel du constructeur en double-cliquant sur le graphique et sélectionne l'option de sauvegarde. Le constructeur imprime toutes les informations dans deux fichiers. Ces fichiers sont utilisés par le moteur.
Laissez-moi vous expliquer en détail : l'utilisateur connecte les deux fichiers reçus du constructeur et du moteur (que je fournirai) à son EA (dans l'en-tête de l'EA. Je fournirai un exemple de connexion). Ensuite, il écrit plusieurs appels dans les fonctions OnInit(), OnTimer(), OnChartEvent() et OnDeinit() (je fournirai un exemple). Ensuite, va dans un fichier imprimé par le constructeur appelé Internal_API. Ce fichier contient tout ce qui est nécessaire pour connecter les contrôles de l'interface graphique à l'indicateur Expert Advisor/utilisateur. Il s'agit des fonctions générées par les éléments et des instructions détaillées. Je fournirai des exemples de connexion plus tard.
Encore une fois, rien de compliqué. Tout est là. Voici par exemple à quoi cela ressemble avec l'interface ci-dessus :
1. Écriture d'une fenêtre.
2. Suivre les instructions ci-dessous :
3.
4. ouvrez le fichier InternalAPI et démarrez la connexion. Le fichier contient tout.
L'utilisateur n'a qu'à écrire ses actions dans les conditions de la fonction OnGuiEvent(). Le reste n'a pas besoin d'être touché.
La commutation de l'état des contrôles, ainsi que l'obtention/le réglage de leurs valeurs se font à l'aide de fonctions générées par le constructeur, que l'utilisateur verra dans l'intellisense.
D'après le code du fichier ci-dessus, l'utilisateur ne travaille qu'avec cette partie :
Nicholas, bonjour !
Je répondrai dans l'ordre :
1. L'utilisateur n'interagira PAS (du tout) avec mon code. Ce n'est pas nécessaire. Vous comprendrez ensuite pourquoi. L'utilisateur n'a besoin QUE du langage de balisage. (J'ai déjà insisté sur ce point à plusieurs reprises, mais les programmeurs me posent toujours cette question récurrente. ) La raison en est que l'utilisateur "initialise" le tableau uniquement à l'aide de mots-clés du langage qui sont définis par des "defines" dans le code du constructeur. L'interprète (l'indicateur) envoie un tableau avec le code de balisage (celui que j'ai montré ci-dessus) au constructeur (qui est l'EA sur le même graphique) et le constructeur lit le tableau et construit l'interface graphique. Le code du langage de balisage est une instruction pour le constructeur. Il exécute la construction (dessin, initialisation des paramètres des éléments, réglages, etc.
2. Le mécanisme est simple. Après avoir terminé l'édition de l'interface, l'utilisateur appelle le menu contextuel du constructeur en double-cliquant sur la carte et sélectionne l'option de sauvegarde. Le constructeur imprime toutes les informations dans deux fichiers. Ces fichiers sont utilisés par le moteur.
Laissez-moi vous expliquer en détail : l'utilisateur connecte les deux fichiers reçus du constructeur et du moteur (que je fournirai) à son EA (dans l'en-tête de l'EA. Je fournirai un exemple de connexion). Ensuite, il écrit plusieurs appels dans les fonctions OnInit(), OnTimer(), OnChartEvent() et OnDeinit() (je fournirai un exemple). Ensuite, va dans un fichier imprimé par le constructeur appelé Internal_API. Ce fichier contient tout ce qui est nécessaire pour connecter les contrôles de l'interface graphique à l'indicateur Expert Advisor/utilisateur. Il s'agit des fonctions générées par les éléments et des instructions détaillées. Je fournirai des exemples de connexion plus tard.
Encore une fois, rien de compliqué. Tout est là. Voici par exemple à quoi cela ressemble avec l'interface ci-dessus :
1. Nous avons écrit une fenêtre.
2. Nous avons suivi les instructions ci-dessous :
3.
4. Ouvrez le fichier InternalAPI et démarrez la connexion. Le fichier contient tout.
L'utilisateur doit seulement spécifier ses actions dans les conditions de la fonction OnGuiEvent(). Le reste n'a pas besoin d'être touché .
La commutation de l'état des contrôles et l'obtention/le réglage de leurs valeurs se font à l'aide de fonctions générées par le constructeur, que l'utilisateur verra dans l'intellisense.
Peter, je ne vous comprends pas.
Vous n'avez pas répondu aux questions. Il est important que les programmeurs sachent comment interagir avec votre interface graphique lorsqu'ils travaillent. Voici un exemple de mon interface graphique. J'ai cliqué sur le raccourci du thème clair/foncé et cet événement a immédiatement déclenché la fonction permettant de modifier les couleurs et les lignes d'arrière-plan. Comment réaliser cette interaction ?
Que signifie "L'utilisateur n'interagira PAS (du tout) avec mon code " ? Le programmeur doit interagir, non pas avec le code, mais avec les événements qui devraient générer ce code. Après tout, l'interface graphique n'est pas un programme indépendant séparé. L'interface graphique doit en fin de compte interagir avec le programme principal du développeur. Qu'il s'agisse d'un indicateur ou d'un EA.