GUI à l'initiative de la foule. Test bêta ouvert. - page 8
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
que tout se passe dans le cadre du style habituel. Il y a certains moments, comme le bouton de lien, le bouton de survol, le bouton de clic, et juste le bouton. Et pour chaque moment, ils créent généralement leurs propres styles, ou un mélange de ceux-ci.
À vrai dire, j'ai toujours mal compris dans ce genre de choses comment organiser les paramètres du code exécuté pour un bouton. Pour que ce soit aussi visuel. Et aussi avec ses propres contrôles d'erreurs dans le code.
Un exemple frappant d'un tel travail serait de créer un menu pour créer un menu. C'est-à-dire, si graphiquement il sera possible de faire le menu de gauche ou de droite avec le code embarqué pour ainsi dire à la volée.
Ou est-ce qu'il ne fait que générer des boutons dans le code.... ?
La mise en place des styles n'est que le début de l'édition. Ensuite, le nombre de fonctionnalités va croître à la manière d'une avalanche. La tâche principale consiste à glisser et déposer les caractéristiques de base du langage de balisage dans l'éditeur visuel. Ce n'est pas difficile à faire. Je dirais qu'il y a une sorte de percée au niveau visuel, comme le franchissement d'une barrière supersonique. C'est difficile à décrire... - c'est comme si les possibilités étaient enfermées sous une serrure et maintenant, quand tu vas voir, la porte s'ouvre et elles s'empilent. Juste le temps de mettre en œuvre.
Tâches à venir :
1. Ajout de fenêtres.
2. Suppression d'éléments.
3. Création d'un nouvel outil - cadre bleu.
4. Copie d'éléments à l'intérieur de la fenêtre.
5. Élargir le champ d'action de l'édition.
6. Ajout de cibles d'édition.
7. Sélection et chargement des projets enregistrés.
8. Mise à niveau du moteur.
...
//------------------------------------------------
Le code n'est pas essentiellement généré. Un noyau contenant les éléments de la description numérique est généré. Il est lu par le moteur attaché à l'application utilisateur et gère la communication bidirectionnelle.
La mise en place de styles n'est que le début de l'édition. Ensuite, le nombre de fonctionnalités va croître comme une avalanche. La tâche principale consiste à glisser et déposer les caractéristiques de base du langage de balisage dans l'éditeur visuel. Ce n'est pas difficile à faire. Je dirais qu'il y a une sorte de percée au niveau visuel, comme le franchissement d'une barrière supersonique. C'est difficile à décrire... - c'est comme si les possibilités étaient enfermées sous une serrure et maintenant, quand tu vas voir, la porte s'ouvre et elles s'empilent. Juste le temps de mettre en œuvre.
Tâches à venir :
1. Ajout de fenêtres.
...
//------------------------------------------------
Le code n'est pas essentiellement généré. Ce qui est généré est un noyau contenant les éléments de la description numérique. Il est lu par le moteur attaché à l'application utilisateur et gère la communication bidirectionnelle.
Ce que je voudrais : créer un style de base et le modifier, créer des styles par défaut. Personnaliser le style des boutons séparément. Il convient de mettre davantage l'accent sur les modèles de style, en s'inspirant de la tendance moderne.
Possibilité de modifier au moins en partie le code des fichiers utilisateur à la volée. Par exemple, l'appel de certaines classes ou la liste à afficher. Par conséquent, il doit s'agir de la norme d'une certaine réponse pour un post-traitement ultérieur.
Il est logique qu'il y ait une possibilité d'édition visuelle - mais ce n'est que la première étape, dans laquelle je pense qu'il est logique d'utiliser le bouton droit et d'y faire un menu défini. En général, il est plus facile de rendre le code indépendant - parce qu'à l'avenir, vous pourriez en avoir besoin non seulement pour travailler dans MT. En conséquence, les fichiers sont enfichables. Au moins dans les inludes si nous le faisons pour le marché.
Habituellement, dans ce genre de direction, chaque nouvelle étape entraîne encore plus de problèmes dans le code, il semble souvent que tout peut être fait en un certain temps, mais en fait cela prend beaucoup plus de temps. Et ce sera toujours le cas, l'avalanche au sens figuré ne fera qu'augmenter les fonctionnalités après la sortie de la première version entièrement fonctionnelle.
Ce qui serait souhaitable : créer un style de base et le modifier, créer des styles par défaut. Personnalisez le style des boutons séparément. Il convient de mettre davantage l'accent sur les modèles de style en s'inspirant de la tendance actuelle.
Possibilité de modifier au moins en partie le code des fichiers utilisateur à la volée. Par exemple, un appel pour certaines classes ou une liste, qui doit être montrée. Il doit donc y avoir une réponse standard pour le post-traitement ultérieur.
Il est logique qu'il y ait une large possibilité d'édition visuelle - mais ce n'est que la première étape, où je pense qu'il est logique d'utiliser le bouton droit et d'y faire un menu défini. En général, il est plus facile de rendre le code indépendant - parce qu'à l'avenir, vous pourriez en avoir besoin non seulement pour travailler dans MT. En conséquence, les fichiers sont enfichables. enfin, au moins dans les inludes si nous le faisons pour le marché
Je vais penser à sauvegarder les modèles de style. Dans un langage de balisage, c'était facile. Dans ce cas, la chaîne de propriétés pourrait être simplement copiée d'un élément à l'autre et l'apparence serait parfaite. Ici, nous n'avons pas de chaîne directe, mais quel est le problème d'en fabriquer une ? Je pense que cela pourrait être mieux et plus simple. Quelque chose comme un jeu de styles avec des valeurs enregistrées des propriétés des modèles...
À propos de la possibilité de modifier les fichiers utilisables - on ne comprend pas très bien de quoi il s'agit exactement. Un exemple serait...
Les fichiers nécessaires à la connexion sont imprimés. Il y en a deux. Ils contiennent les informations de chargement pour le moteur et l'api pour l'application utilisateur. Pour qu'il "communique" avec les éléments.
Imprimez du texte sur les éléments.
pensez à la grille - une certaine forme d'alignement est nécessaire. il est déjà difficile d'aligner trois éléments de manière égale
Je suis d'accord. Je vais y réfléchir.
pensez à la grille - un certain type d'alignement/liaison est nécessaire.
Oui, cette grille entière est 10 fois plus grande que .......
Besoin de voir l'intérêt de l'utilisateur. Par exemple s'il était possible de créer tel ou tel graphique à la volée... par exemple tracer une ligne par les maxima et ainsi de suite.
Parce que jusqu'à présent, ce n'est rien de plus qu'une très bonne leçon pour l'auteur en matière de conception de programmes. La simple création d'un menu n'est pas très intéressante. Et les appels de fonction doivent provenir d'un bouton.
Bien que, en raison de la popularisation de canvas sur html, il y a un intérêt sportif à implémenter quelque chose d'universel. Mais c'est trop compliqué pour moi
....
Certes, il existe une autre option - se limiter à la génération de code. Comme un "inludnik" avec tous les boutons, la mise en page est créée et il ne reste plus qu'à saisir les données ........ - également une variante. PS : L'option la plus proche et la plus viable
Mon objectif est de mettre en œuvre la liste de tâches suivante d'ici le 3 mars :
1. Ajout/suppression de fenêtres.
2. Suppression d'éléments.
3. Création d'un nouvel outil - cadre bleu.
4. Copie d'éléments à l'intérieur de la fenêtre.
5. Élargir le champ d'action de l'édition.
6. Ajout de cibles d'édition.
7. Sélection et chargement des projets enregistrés.
8. Mise à niveau du moteur.
9. Grille et correction automatique de la position des éléments.
//------------------------------------------------
Ensuite, l'éditeur visuel peut être utilisé pour créer une interface utilisateur de type Windows pour l'application.
(sic. avec un ensemble d'éléments simples. Elle sera suivie de tableaux et de listes diverses).
Peter a inventé et écrit Windows ! Juste 30 ans trop tard =)
Sur les traces des géants).