Sur les formulaires classiques, l'emplacement des éléments est dessiné entièrement manuellement. Pour faciliter ce processus, la plateforme propose plusieurs mécanismes :

- alignement des éléments- permet un centrage automatique, ou un « appui » des commandes les unes sur les lignes directrices des autres, ou un alignement des tailles des commandes :

- filet- grâce aux Options vous pouvez configurer l'affichage de la grille pour un alignement manuel précis des éléments :

La bonne réponse est la deuxième. Il s'agit d'un panneau permettant d'aligner et d'unifier les tailles des éléments.

Question 10.79 de l'examen 1C : Plateforme Professionnelle.

1. Rien ne changera
2. L'élément "Inscription1" sera décalé horizontalement et sa bordure droite sera alignée avec la bordure droite de l'élément "Inscription2"
3. L'élément "Inscription2" sera décalé horizontalement et sa bordure droite sera alignée avec la bordure droite de l'élément "Inscription1"
4. Les deux éléments seront déplacés vers la ligne d'alignement du bord droit du formulaire.

La bonne réponse est la deuxième. Les étiquettes seront alignées à droite.

Question 10.82 de l'examen 1C : Plateforme Professionnelle. Que se passe-t-il lorsque vous cliquez sur le bouton de la barre de commandes indiqué dans l'image ?

1. Toutes les inscriptions auront la même taille horizontalement
2. Rien ne changera
3. Les étiquettes vont changer. L'axe vertical de symétrie de chaque élément de commande coïncidera avec l'axe vertical de symétrie de la forme, c'est-à-dire centrer chaque contrôle horizontalement
4. Les étiquettes se déplaceront horizontalement. Les commandes ne bougeront pas les unes par rapport aux autres au sein du groupe, c'est-à-dire centrer, pour ainsi dire, un élément dans son ensemble
5. Les étiquettes se déplaceront verticalement. Les commandes ne bougeront pas les unes par rapport aux autres au sein du groupe, c'est-à-dire centrer, pour ainsi dire, un élément dans son ensemble

La bonne réponse est la quatrième. Tous les contrôles sélectionnés seront centrés autour de leur ligne centrale commune.

Question 10.83 de l'examen 1C : Plateforme Professionnelle. Que se passe-t-il lorsque vous cliquez sur le bouton de la barre de commandes indiqué dans l'image ?

1. Toutes les inscriptions auront la même taille verticalement. L'élément de contrôle "Inscription1" sera pris comme échantillon.
2. Rien ne changera
3. Toutes les inscriptions auront la même taille verticalement. L'élément de contrôle "Inscription3" sera pris comme échantillon.
4. Chaque étiquette sera centrée verticalement
5. Il y aura une répartition uniforme des inscriptions dans le sens vertical. Les contrôles "Inscription1" et "Inscription3" resteront en place, et l'élément "Inscription2" sera déplacé dans le sens souhaité. Lors du déplacement d'un élément, l'accrochage à la grille de mise en page n'est pas pris en compte
6. Il y aura une répartition uniforme des inscriptions dans le sens vertical. Les contrôles "Inscription1" et "Inscription3" resteront en place, et l'élément "Inscription2" sera déplacé dans le sens souhaité. Lorsque vous déplacez un élément, il s'alignera sur la grille de marquage si le mode de son utilisation est défini

La bonne réponse est la première. La hauteur des éléments sera standardisée

Question 10.86 de l'examen 1C : Plateforme Professionnelle. Que se passe-t-il si vous cliquez sur le bouton de la barre de commandes annulé dans l'image ?

1. Toutes les inscriptions auront la même taille verticalement et horizontalement. L'élément de contrôle "Inscription1" sera pris comme échantillon.
2. Toutes les inscriptions auront la même taille verticalement et horizontalement. L'élément de contrôle "Inscription3" sera pris comme échantillon.
3. Rien ne changera
4. Les étiquettes seront automatiquement alignées
5. Toutes les étiquettes auront un fond transparent.

La bonne réponse est la numéro quatre, le bouton lui-même s'appelle « Aligner automatiquement »

Question 10.90 de l'examen 1C : Plateforme Professionnelle. Désactivez le mode d'alignement à l'aide de lignes d'alignement dans un formulaire créé précédemment :

1. C'est interdit
2. Peut. Pour ce faire, dans la palette des propriétés du formulaire, vous devez désactiver la propriété "Utiliser les lignes d'alignement".
3. Peut. Pour ce faire, en sélectionnant l'élément du menu principal "Outils-Options", dans l'onglet "Formulaire", vous devez désactiver la propriété "Utiliser les lignes d'alignement".
4. Peut. Pour ce faire, dans la palette des propriétés du formulaire, vous devez désactiver la propriété "Utiliser les lignes d'alignement" ou, en sélectionnant l'élément de menu principal "Outils-Options", dans l'onglet "Formulaire", désactiver la propriété "Utiliser les lignes d'alignement".

La bonne réponse est la deuxième. Les lignes d'alignement (marquées d'une flèche) sont désactivées par la propriété de formulaire correspondante :

Question 10.92 de l'examen 1C : Plateforme Professionnelle. Lors de l'alignement des éléments du formulaire, une grille de mise en page peut s'afficher :

1. Lignes continues
2. Points en damier
3. Points situés à l'intersection des lignes de marquage
4. Les réponses 1 et 2 sont correctes
5. Les réponses 2 et 3 sont correctes
6. Les réponses 1, 2 et 3 sont correctes

La bonne réponse est la cinquième. L'emplacement des points est contrôlé par l'option Damier dans les paramètres système (voir capture d'écran dans l'article).

Question 10.95 de l'examen 1C : Plateforme Professionnelle.

1. Un marqueur d'alignement spécial qui montre le décalage des contrôles. Il est proposé de déplacer l'élément de contrôle sélectionné vers la gauche
2. Un marqueur d'alignement spécial qui montre le décalage des contrôles. L'élément de contrôle sélectionné est proposé pour être déplacé vers le bas
3. Un marqueur d'alignement spécial montrant la superposition des contrôles. Il est proposé de déplacer l'élément de contrôle sélectionné vers la gauche
4. Un marqueur d'alignement spécial montrant la superposition des contrôles. L'élément de contrôle sélectionné est proposé pour être déplacé vers le bas

La bonne réponse est la première. La marge inférieure est décalée vers la droite par rapport au haut, il est donc proposé de la déplacer vers la gauche.

Question 10.96 de l'examen 1C : Plateforme Professionnelle. Puis-je utiliser des lignes d’alignement pour redimensionner et déplacer les contrôles de formulaire ?

1. C'est interdit
2. Oui, si les champs sont rattachés à ces lignes
3. C'est possible si les champs sont attachés à ces lignes, mais seulement les déplacer
4. C'est possible si les champs sont attachés à ces lignes, mais uniquement redimensionnés
5. Tu peux toujours

La bonne réponse est la deuxième. Les éléments attachés à un même hauban peuvent être déplacés ensemble.

Question 10.97 de l'examen 1C : Plateforme Professionnelle. Sur la figure, le cercle rouge indique :

1. Un marqueur d'alignement spécial qui montre le décalage des contrôles. L'élément de contrôle sélectionné est proposé pour être déplacé vers la gauche et vers le haut
2. Un marqueur d'alignement spécial qui montre le décalage des contrôles. L'élément de contrôle sélectionné peut être déplacé vers la droite et vers le bas
3. Un marqueur d'alignement spécial montrant la superposition des contrôles. L'élément de contrôle sélectionné est proposé pour être déplacé vers la gauche et vers le haut
4. Un marqueur d'alignement spécial montrant la superposition des contrôles. L'élément de contrôle sélectionné peut être déplacé vers la droite et vers le bas

La bonne réponse est la quatrième. Là où pointent les flèches, vous devez vous y déplacer.

Question 10.98 de l'examen 1C : Plateforme Professionnelle. Sur la figure, le cercle rouge indique :

Question 10.110 de l'examen 1C : Plateforme Professionnelle. Comment puis-je utiliser le bouton de la barre de commandes illustré dans la figure pour aligner les trois étiquettes à droite ?

1. Sélectionnez tout d'abord le champ « Inscription1 » en cliquant dessus avec le bouton gauche de la souris et en appuyant simultanément sur la touche . Appuyez ensuite sur le bouton indiqué
2. Cliquez simplement sur le bouton indiqué
3. En utilisant ce bouton, vous ne pouvez pas aligner les étiquettes, car elles appartiennent à des panneaux différents

La bonne réponse est la troisième. L'alignement fonctionne au sein d'un seul panneau.

Question 10.115 de l'examen 1C : Plateforme Professionnelle. Pour afficher une grille de mise en page dans un formulaire existant, il suffit :

1. Dans la palette des propriétés du formulaire, définissez la propriété "Utiliser la grille".
2. En sélectionnant l'élément du menu principal "Outils-Options", dans l'onglet "Formulaire", cochez le drapeau "Utiliser la grille".
3. En sélectionnant l'élément du menu principal "Outils-Options", dans l'onglet "Formulaire", cochez le drapeau "Grille d'affichage".
4. En sélectionnant l'élément du menu principal "Outils-Options", dans l'onglet "Formulaire", définissez le drapeau "Afficher la grille", puis dans la palette des propriétés du formulaire, définissez la propriété "Utiliser la grille".
5. En sélectionnant l'élément du menu principal "Outils-Options", dans l'onglet "Formulaire", cochez les drapeaux "Afficher la grille" et "Utiliser la grille".

La bonne réponse est la quatrième ; pour le formulaire, vous pouvez également spécifier l'option d'affichage ou non.

19.05.2015

Implémenté dans la version 8.3.7.1759.

Pour bien comprendre de quoi nous parlons dans cet article, il est nécessaire de faire une petite explication.

Une caractéristique des formulaires gérés est que le développeur ne façonne pas directement l’apparence du formulaire. Le développeur crée uniquement une description du formulaire en utilisant quelques règles logiques. Sur la base de ces règles, la plateforme génère indépendamment une représentation visuelle du formulaire. De plus, cette représentation visuelle dépend de la taille de la fenêtre dans laquelle le formulaire est affiché. Le même formulaire affiché dans une fenêtre étroite ou dans une fenêtre agrandie en plein écran aura une apparence visuelle différente.

Ainsi, la partie de la plate-forme qui forme la représentation visuelle du formulaire est appelée le mécanisme permettant de placer des éléments dans le formulaire.

Pourquoi un nouveau mécanisme était-il nécessaire ?

Premièrement, le mécanisme précédent présentait malheureusement des lacunes. Le plus important d'entre eux était que de nombreuses modifications apportées aux propriétés des éléments de formulaire effectuées sur le client nécessitaient un appel au serveur. Et tout accès au serveur entraîne un ralentissement.

Deuxièmement, nous avons évalué l'expérience d'utilisation des formulaires gérés et découvert un certain nombre de besoins critiques qui devaient être satisfaits.

Et troisièmement, nous voulions intégrer dans le nouveau mécanisme des opportunités de développement futur.

Changements majeurs

Le fonctionnement du mécanisme précédent peut être schématiquement représenté comme suit :

Le développeur crée une arborescence d'éléments de formulaire dans le configurateur et définit les propriétés des éléments. Au moment où la solution applicative doit montrer le formulaire à l'utilisateur, ce qui suit se produit. Tout d'abord, la plateforme crée une description de la forme visuelle sur le serveur. Ensuite cette description est transmise au client. Et sur le client, le visualiseur génère l'image que l'utilisateur verra.

La principale action effectuée sur le serveur lors de la création d'une description de la forme visuelle était le calcul des longueurs des lignes. Cela fait référence à toutes sortes de titres, d'inscriptions, etc. Connaissant les longueurs des lignes, vous pouvez déjà calculer la disposition des éléments dans le formulaire.

Cette opération étant effectuée sur le serveur, il y avait deux aspects négatifs. Premièrement, pour le calcul nous avons utilisé non pas les polices qui seront utilisées sur le client, mais celles installées sur le serveur. Et ils peuvent différer, notamment lorsqu’il s’agit de différentes plateformes (Windows, Linux). Ou même les polices nécessaires peuvent ne pas être installées du tout sur le serveur. Deuxièmement, pour calculer les longueurs, nous avons utilisé le moteur de rastérisation des polices qui se trouve sur le serveur. Et cela peut ne pas fonctionner exactement comme le mécanisme de rendu des chaînes de texte qui existe sur le client dans un navigateur Internet, par exemple. De ce fait, des formulaires pouvaient apparaître soit avec des textes « tronqués », soit, à l'inverse, avec des inscriptions trop larges.

Un autre problème était qu'il n'y avait pas d'adaptation à la taille de la fenêtre dans laquelle le formulaire serait présenté au client. En fait, sur le serveur, la description du formulaire a été créée sur la base de la taille minimale possible de la fenêtre, et le succès ultérieur de son affichage dépendait de sa capacité à s'étirer.

Dans le nouveau mécanisme, nous avons divisé la génération d'une description d'un formulaire visuel, qui était auparavant entièrement réalisée sur le serveur, en deux parties, serveur et client :

La partie serveur est devenue nettement plus petite. Il n'effectue aucun calcul. Seule une description « vierge » est créée sur le serveur, qui ne contient pas la longueur exacte des champs de texte, et les éléments d'adaptabilité n'y sont pas autorisés. Le serveur gère la visibilité des éléments, mais uniquement celle qui est déterminée par les options fonctionnelles et celle définie par l'utilisateur. Mais ici, il est impossible de faire autrement, car les options fonctionnelles elles-mêmes ne sont disponibles que sur le serveur. Et la modification interactive des paramètres par l'utilisateur entraînera dans tous les cas un appel au serveur.

Le résultat est une sorte de « produit semi-fini » d'une représentation visuelle de la forme, qui est transférée au client.

Les modifications nécessaires à la description de la forme visuelle sont apportées au client. Les longueurs de lignes sont calculées, les éléments de réactivité liés à la taille de l'écran client sont calculés et la visibilité est élaborée. Après cela, comme auparavant, le visualiseur commence à fonctionner, ce qui crée le formulaire final que voit le client.

Du fait que le calcul des longueurs de chaînes est effectué par le client, nous avons pu nous débarrasser des « espaces » inutiles et bâclés entre les éléments. Et travailler la visibilité sur le client sans accéder au serveur a permis d'accélérer le travail des formulaires. Parce qu'activer/désactiver la visibilité des éléments de formulaire est l'une des opérations les plus courantes.

Quelques nouveautés

Éléments d'interface réactifs

Le nouveau mécanisme de placement d'éléments sur le formulaire améliore non seulement les fonctionnalités disponibles auparavant, mais ajoute également de nouvelles fonctionnalités. Par exemple, il adapte l'apparence du formulaire à la taille de l'affichage client. Il y a plusieurs moyens de le faire.

Tout d’abord, un retour à la ligne automatique est effectué, ajustant la hauteur des titres et des décorations. Vous pouvez voir comment cela fonctionne sur la figure :

S'il y a de longues lignes dans le formulaire qui peuvent être divisées en mots individuels, ces lignes sont alors renvoyées à la ligne si nécessaire. En conséquence, la hauteur de la forme augmente, car sa partie inférieure « descend ». En conséquence, le formulaire semblera normal même sur des écrans étroits. De plus, ce mécanisme fonctionne de manière dynamique, ce qui signifie que vous pouvez compresser le formulaire en temps réel et que de longues lignes s'enrouleront avec lui.

L'habillage automatique fonctionne pour les titres d'éléments, les titres de groupes, les décorations de texte et le texte des boutons dotés de la vue Lien hypertexte.

Le deuxième élément de l’adaptabilité consiste à changer l’orientation des groupes. Les groupes et le formulaire dans son ensemble disposent d'une nouvelle option d'orientation : « Horizontale si possible ». Dans cette option, si l'afficheur client permet de positionner les éléments horizontalement, ceux-ci sont positionnés horizontalement. Sinon, ils sont situés verticalement.

Le troisième élément d'adaptabilité est la détermination automatique du nombre de colonnes d'un interrupteur ou d'un interrupteur à bascule. Auparavant, sauf instructions particulières, le nombre de colonnes était fixé au maximum et affiché sur une seule ligne. Maintenant, dans la même situation, la largeur du formulaire est analysée et le nombre de colonnes est défini de manière à ce que l'interrupteur/interrupteur à bascule apparaisse bien à l'écran.

Alignement horizontal et vertical

Auparavant, cette possibilité était absente et pour mettre en œuvre un alignement non standard, il fallait inventer diverses « astuces ». Le formulaire et le groupe peuvent désormais être spécifiés comment leurs éléments doivent être alignés verticalement et horizontalement. Par exemple, dans l'image ci-dessous, un groupe de boutons affiche trois options d'alignement possibles : Gauche, Centre et Droite :

Sur cette image, les boutons sont placés dans un groupe régulier qui s'étend horizontalement. Le placement des boutons au sein d'un groupe est contrôlé par la propriété HorizontalPositionSubordonnées du groupe.

Contrôle d'alignement externe

Par exemple, vous disposez d'un formulaire dans lequel se trouvent le champ Département, les groupes Adresse et Téléphone. Le mécanisme précédent alignait les champs de ces groupes comme le montre la figure de gauche. Les champs du formulaire étaient alignés les uns avec les autres et les champs de chaque groupe étaient alignés les uns avec les autres.

Vous avez désormais la possibilité de définir un alignement de bout en bout pour les groupes, grâce auquel, par exemple, tous les champs du formulaire seront alignés de la même manière. Cette option est affichée dans l'image de droite.

De plus, vous pouvez gérer l'alignement de bout en bout pour chaque groupe séparément. Par conséquent, vous pouvez, par exemple, désactiver l'alignement de bout en bout pour le groupe Téléphone, et le formulaire ressemblera alors à celui illustré dans la figure de droite.

Alignement des éléments et des titres

Une autre nouvelle fonctionnalité apparue est la possibilité de contrôler la position relative des éléments et des titres. Aussi bien sous toutes les formes qu’en groupes individuels. Par exemple, vous pouvez « étirer » les titres et les éléments sur différents bords du formulaire, ou vice versa, les « tirer » les uns vers les autres, en alignant les titres à droite et les éléments à gauche.

Limiter la largeur maximale des éléments

Auparavant, si vous demandiez à un élément de s'étirer, il s'étirait aussi loin qu'il le pouvait. Par exemple, plein écran. Pour certains éléments, c'était bien (comme un champ HTML), mais pour d'autres éléments, ce n'était peut-être pas aussi bien. Par exemple, pour les champs numériques. Parce que les données numériques, ou les boutons qui contrôlent le champ, se trouvaient quelque part très à droite.

Les éléments ont désormais des propriétés booléennes, avec lesquelles vous pouvez définir le mode d'étirement automatique en largeur ou en hauteur. Dans ce mode, la plateforme détermine indépendamment jusqu'où le champ peut être étendu. Si le mode automatique est désactivé, alors la plateforme se comportera de la même manière qu'auparavant. Si vous spécifiez une largeur/hauteur de champ spécifique, celle-ci sera utilisée. Et si vous spécifiez la valeur 0, l'élément s'étirera autant que possible.

Contrôler l'espacement entre les éléments

Il est également possible de contrôler l'espacement horizontal et vertical entre les éléments. Par exemple, dans la figure suivante, le groupe de gauche présente un espacement vertical accru, tandis que le groupe de droite présente un espacement vertical réduit.

Désactiver l'étirement du formulaire

Nous avons implémenté un autre nouveau mode de fonctionnement du formulaire, qui désactive l'étirement vertical de ses éléments. Ce mode sera utile pour les formulaires contenant un petit nombre d'éléments.

Désactiver le défilement des pages

Pour les formulaires contenant un grand nombre d’éléments, nous avons également légèrement modifié le comportement. Désormais, le défilement vertical n'apparaît pas sur les pages. Le défilement vertical peut désormais s'effectuer sur le formulaire lui-même ou à l'intérieur d'éléments de formulaire, tels qu'un tableau, une feuille de calcul, etc. Et la page du formulaire sera toujours en pleine hauteur. Cela devrait rendre l'expérience utilisateur plus facile, car un grand nombre de scrollers sur un formulaire peut souvent être déroutant et déroutant.

Résumé

Dans cet article de synthèse, nous n'avons répertorié que les principales fonctionnalités apportées par le nouveau mécanisme de placement d'éléments dans le formulaire. Mais ce qui est tout aussi important, à notre avis, est que ce mécanisme contient une réserve importante pour un développement futur.

Et objet de transfert de données à la structuration du code, forme contrôlée dans l'environnement 1C 8.2.

Introduction

Commençons par une brève description du concept de « formulaire géré » et des concepts associés de la plateforme 1C. Les connaisseurs de la plateforme voudront peut-être ignorer cette section.

En 2008, une nouvelle version de la plateforme 1C : Enterprise 8.2 (ci-après dénommée Application Gérée) est devenue disponible, ce qui change complètement toute la couche de travail avec l'interface. Cela inclut l'interface de commande, les formulaires et le système de fenêtres. Dans le même temps, non seulement le modèle de développement de l'interface utilisateur dans la configuration change, mais une nouvelle architecture est également proposée pour séparer les fonctionnalités entre l'application client et le serveur.
L'application gérée prend en charge les types de clients suivants :

• Client lourd (mode de lancement normal et géré)
• Client léger
• Client Web

L'application gérée utilise des formulaires basés sur une nouvelle technologie. Ils s'appellent Formulaires gérés. Pour faciliter la transition, les formulaires précédents (appelés formulaires Regular) sont également pris en charge, mais leurs fonctionnalités ne sont pas développées et ils ne sont disponibles qu'en mode de lancement du client lourd.
Les principales différences des formulaires gérés pour un développeur :

• Description déclarative et non « pixel par pixel » de la structure. Le placement spécifique des éléments est effectué automatiquement par le système lors de l'affichage du formulaire.
• Toutes les fonctionnalités du formulaire sont décrites comme détails Et équipes. Les détails sont les données avec lesquelles le formulaire fonctionne et les commandes sont les actions à effectuer.
• Le formulaire s'exécute à la fois sur le serveur et sur le client.
• Dans le contexte client, presque tous les types d'applications sont indisponibles et, par conséquent, il est impossible de modifier les données de l'infobase.
• Pour chaque variable de méthode ou de formulaire, il faut préciser directive de compilation, définissant l'emplacement d'exécution (client ou serveur) et l'accès au contexte du formulaire.

Listons les directives pour compiler les méthodes de formulaire :

• &SurClient
• &Sur le serveur
• &Sur le serveur sans contexte
• &SurClientSurServeurSans contexte

Illustrons ce qui précède. La capture d'écran montre un exemple de formulaire géré et son module en mode développement. Recherchez la description déclarative, les accessoires, les directives de compilation, etc.

Toutes les discussions ultérieures porteront sur le côté droit de l'illustration, sur la façon de structurer le code du module et sur les principes qui vous permettront de mettre en œuvre une interaction client-serveur efficace.

Définissons le problème

Plusieurs années se sont écoulées depuis que la nouvelle version de la plateforme 1C est activement utilisée et de nombreuses solutions (configurations) ont été publiées à la fois par 1C et par ses nombreux partenaires.
Pendant ce temps, les développeurs ont-ils développé une compréhension commune des principes d'interaction client-serveur lors de la création de formulaires, et l'approche de mise en œuvre des modules logiciels a-t-elle changé dans les nouvelles réalités architecturales ?

Examinons la structure du code (module de formulaire) dans plusieurs formes de la même configuration standard et essayons de trouver des modèles.
Par structure, nous entendons des sections de code (le plus souvent il s'agit de blocs de commentaires) allouées par le développeur aux méthodes de groupe et aux directives de compilation pour ces méthodes.
Exemple 1:
Section des gestionnaires d'événements Méthode - sur le client Méthode - sur le serveur Méthode - sur le client Section des procédures et fonctions de service Fonctions de contrôle des entrées auxiliaires
Exemple 2 :
Procédures et fonctions de service Documents de paiement Valeurs Gestionnaires d'événements
Exemple 3 :
Procédures de service sur le serveur Procédures de service sur le client Procédures de service sur le serveur sans contexte Gestionnaires d'événements d'en-tête Gestionnaires d'événements de commande
Exemple 4 :
Procédures générales Gestionnaires d'événements de formulaires Procédures du sous-système « informations de contact »
Essentiellement, la structure du code est manquante, ou, pour le moins, elle est similaire à celle de Forms 8.1 :

• Mots non informatifs « Général, Service, Auxiliaire ».
• Tentatives timides de séparer les méthodes client et serveur.
• Les méthodes sont souvent regroupées par éléments d'interface « Travailler avec la partie tabulaire Produits, Coordonnées ».
• Disposition arbitraire des méthodes et des groupes de codes. Par exemple, les gestionnaires d'événements peuvent être en haut dans une forme, en bas dans une autre, pas du tout mis en évidence dans une troisième, etc.
• Et n'oublions pas que tout cela se déroule dans une seule configuration.
• Oui, il existe des configurations dans lesquelles les mots « Général, Service, Auxiliaire » sont toujours aux mêmes endroits mais...

Pourquoi avez-vous besoin d’une structure de code ?

• Simplification de l'entretien.
• Simplifiez l'apprentissage.
• Enregistrer les principes généraux/importants/réussis.
• ...votre choix

Pourquoi la norme de développement existante de 1C n'est-elle pas utile ?

Regardons les principes publiés sur les disques ITS et dans divers « Guides du développeur... » qui sont recommandés lors de l'écriture d'un formulaire géré.

• Minimisez le nombre d’appels au serveur.
• Calcul maximum sur le serveur.
• Les appels serveur non contextuels sont plus rapides que les appels contextuels.
• Programme en pensant à la communication client-serveur.
• et ainsi de suite.

Ce sont des slogans absolument vrais, mais comment les mettre en œuvre ? Comment minimiser le nombre d'appels, que signifie programmer en mode client-serveur ?

Modèles de conception ou sagesse générationnelle

L'interaction client-serveur est utilisée dans diverses technologies logicielles depuis des décennies. La réponse aux questions évoquées dans la section précédente est connue depuis longtemps et se résume en deux principes de base.

• Façade à distance(ci-après dénommée Interface d'accès à distance)
• Objet de transfert de données(ci-après dénommé Objet de transfert de données)

Un mot de Martin Fowler, sa description de ces principes :

• … Chaque objet potentiellement destiné à un accès distant doit avoir interface à faible granularité, ce qui minimisera le nombre d'appels nécessaires pour effectuer une procédure spécifique. ... Au lieu de demander une facture et tous ses éléments séparément, vous devez lire et mettre à jour tous les éléments de la facture en une seule demande. Cela affecte toute la structure de l'objet... Rappel : interface d'accès à distance ne contient pas de logique de domaine.
• ...si j'étais une mère attentionnée, je dirais certainement à mon enfant : « N'écrivez jamais d'objets de transfert de données ! » Dans la plupart des cas, les objets de transfert de données ne sont rien d'autre que ensemble de champs gonflés... La valeur de ce monstre dégoûtant réside uniquement dans la possibilité transmettre plusieurs informations sur le réseau en un seul appel- une technique d'une grande importance pour les systèmes distribués.

Exemples de modèles dans la plateforme 1C

L'interface de programmation d'application dont dispose le développeur lors du développement d'un formulaire géré contient de nombreux exemples de ces principes.
Par exemple, la méthode OpenForm(), une interface « brute » typique.
OpeningParameters = Nouvelle Structure("Paramètre1, Paramètre2, Paramètre3", Valeur1, Valeur2, Valeur3); Form = OpenForm(FormName, OpeningParameters);
Comparez avec le style adopté dans la v8.1.
Formulaire = GetForm (NomFormulaire); Form.Parameter1 = Valeur1 ; Form.Parameter2 = Valeur2 ; Form.Open();

Dans le cadre d'un formulaire géré, il existe de nombreux « Objets de transfert de données ». Vous pouvez sélectionner systémique Et défini par le développeur.
Ceux du système modélisent un objet application sur le client, sous la forme d'un ou plusieurs éléments de données de formulaire. Il est impossible de les créer sans référence aux détails du formulaire.

• Structure des formulaires de données
• Collection de formulaires de données
• DataFormStructureWithCollection
• Arbre de formes de données

La conversion des objets de transfert de données système en types d'application et vice versa est effectuée à l'aide des méthodes suivantes :

• ValueInFormData()
• FormDataValue()
• CopierFormData()
• ValueInFormAttributes()
• FormAttributesValue()

Une conversion explicite est souvent utilisée lors de l’adaptation d’une solution existante. Les méthodes peuvent attendre (utiliser des fonctionnalités) des paramètres d'entrée, tels que ValueTable plutôt que FormDataCollection, ou la méthode a été définie dans le contexte d'un objet d'application et est devenue indisponible pour un appel direct à partir du formulaire.
Exemple 1C v8.1 :
// sur le client dans le contexte du formulaire FillUserCache(DepartmentLink)
Exemple 1C v8.2 :
// sur le serveur dans le contexte du formulaire ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Les objets de transfert de données, dont la structure est déterminée par le développeur, constituent un petit sous-ensemble des types disponibles à la fois sur le client et sur le serveur. Le plus souvent, comme paramètres et résultats des méthodes d'une interface « grossie » sont utilisés :

• Types primitifs (chaîne, nombre, booléen)
• Structure
• Correspondance
• Tableau
• Liens vers les objets applicatifs (identifiant unique et représentation textuelle)

Exemple : la méthode accepte une liste de commandes à changer de statut et renvoie une description des erreurs au client.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Erreurs = New Match(); // [commande][description de l'erreur] Pour chaque commande du cycle de commandes StartTransaction(); Essayez DocOb = Order.GetObject(); …. d'autres actions, possibles non seulement avec la commande... Exception CancelTransaction(); Erreurs.Insert (Ordre, Description d'erreur ()); FinTentative ; Fin du cycle ; Erreur de retour ; EndFunction // ServerChangeOrderStatus()

Structurer le code

Les principaux objectifs que le module de formulaire géré doit refléter et les approches de la solution.

• Séparation claire du code client et serveur. N'oublions pas qu'au moment de l'exécution, il s'agit de deux processus en interaction, dont chacun a des fonctionnalités disponibles très différentes.
• Identification claire de l'interface d'accès à distance, quelles méthodes du serveur peuvent être appelées depuis le client et lesquelles ne le peuvent pas ? Les noms des méthodes d'interface distante commencent par le préfixe « Serveur ». Cela permet de voir immédiatement le transfert de contrôle vers le serveur lors de la lecture du code, et simplifie l'utilisation de l'aide contextuelle. Notez que la recommandation officielle (ITS) suggère de nommer les méthodes avec des suffixes, par exemple ChangeOrderStatusOnServer(). Cependant, nous répétons que toutes les méthodes du serveur ne peuvent pas être appelées depuis le client et que, par conséquent, l'accessibilité logique est plus importante que l'emplacement de compilation. Par conséquent, avec le préfixe « Serveur », nous marquons uniquement les méthodes disponibles pour le client ; appelons l'exemple de méthode ServerChangeOrderStatus().
• Lisibilité. Question de goût, on accepte la commande lorsque le module commence par les procédures de création d'un formulaire sur le serveur et les méthodes d'accès à distance.
• Maintenabilité. Il doit y avoir un emplacement clair pour ajouter un nouveau code. Un point important est que des modèles de méthodes créés automatiquement par le configurateur sont ajoutés à la fin du module. Étant donné que les gestionnaires d'événements pour les éléments de formulaire sont le plus souvent créés automatiquement, le bloc correspondant est situé en dernier, afin de ne pas faire glisser chaque gestionnaire vers un autre endroit du module.

Vous trouverez ci-dessous la structure de base du module qui met en œuvre les objectifs répertoriés.

• Option graphique – montre clairement le flux principal d’exécution.
• L'option texte est un exemple de conception de modèle permettant d'insérer rapidement une structure dans un nouveau module de formulaire.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Date=""/> // <Описание> // // ///////////////////////////////////////////// // ////////////////////////// // VARIABLES DU MODULE ///////////////// // /////////////////////////////////////////// //// ////////// // SUR LE SERVEUR //******* EVENEMENTS SUR LE SERVEUR ******* &Sur la procédure du serveur lors de sa création sur le serveur (Echec, Traitement Standard) / /Insérer le contenu du handler Fin de procédure //******* INTERFACE D'ACCÈS À DISTANCE ******* //******* LOGIQUE BUSINESS SUR LE SERVEUR ******* ///////// ////////////////////////////////////// /////// /////////////////// // METHODES COMMUNES CLIENT ET SERVEUR /////////////// /////// //////////////////////////////////////// ///// //////// // SUR LE CLIENT //******* LOGIQUE BUSINESS SUR LE CLIENT ******* //******* ÉQUIPE * ****** //******* ÉVÉNEMENTS CLIENTS ******* ///////////////////////// ///// ////////////////////////////////////////// // / / PRINCIPAUX OPÉRATEURS DU PROGRAMME

Questions connexes

En conclusion, nous présenterons plusieurs domaines auxquels il est utile de réfléchir lors de la programmation de l’interaction client-serveur.

• Options de mise en œuvre de l'interface d'accès à distance. Asynchronie, niveau de détail...
• Mise en cache. 1C a pris une décision architecturale infructueuse, introduisant la mise en cache uniquement au niveau des méthodes d'appel des modules communs et ne fournissant pas de capacités de contrôle (temps de pertinence, réinitialisation à la demande).
• Appels de serveur implicites. N'oubliez pas les fonctionnalités technologiques : de nombreuses opérations « inoffensives » sur le client provoquent un contact de la plateforme avec le serveur.

Introduction

Formulaires gérés. Un nouveau développement 1C conçu pour faciliter le travail du développeur, en lui donnant plus de temps pour écrire du code en simplifiant la conception de l'interface. En fait, il s'avère souvent que ce qu'on appelle. Les « formes contrôlées » sont totalement incontrôlables. Les UV ne peuvent pas faire des choses aussi banales que minimiser/maximiser une fenêtre, sans parler de son positionnement sur l'écran et de la définition de sa taille en pixels. Peut-être que ces fonctions ont été considérées comme non réclamées et n'ont pas été incluses dans la nouvelle interface, mais la pratique montre qu'elles font parfois très défaut. Depuis quelque temps, le problème a été partiellement résolu par WSH, mais je voulais quelque chose de plus. C’est ainsi qu’un composant externe a été implémenté pour rendre les « formulaires gérés » un peu plus gérables.

Quoi? Où? Quand?

Ce VK est une bibliothèque de fonctions permettant de contrôler l'état et la position des fenêtres. La bibliothèque contient également plusieurs fonctions système utiles.

Contrôle de l'état de la fenêtre :

Développer ( Fenêtre d'en-tête ) — agrandit la fenêtre en plein écran

Réduire (Titre de la fenêtre) - minimise la fenêtre de la barre des tâches

Masquer (Titre de la fenêtre) - masque la fenêtre (pendant que le code du formulaire continue à être exécuté)

Montrer () - montre la dernière fonction cachée fenêtre masquer()

CollapseWindow (WindowTitle) - dans restaure la fenêtre à son état d'origine

VRAIE Visibilité (WindowTitle) - p vérifie si la fenêtre est visible à l'écran

VRAI étendu (titre de la fenêtre) - vérifie si la fenêtre est agrandie en plein écran

VRAI Réduit (WindowTitle) - vérifie si la fenêtre est réduite dans la barre des tâches

Définir la transparence(Titre de la fenêtre, Coefficient) - définit la transparence de la fenêtre. Le degré de transparence est défini à l'aide d'un coefficient (0-255).

Contrôle de la position des fenêtres :

ObtenirPosition(Titre de la fenêtre, X, Oui) - Obtient les coordonnées du coin supérieur gauche de la fenêtre par rapport à l'écran. Les coordonnées sont renvoyées via des paramètresX,Y.

Se déplacer(Titre de la fenêtre, X, Oui) - déplace la fenêtre vers une position spécifiéeXY. Dans ce cas XYsont les coordonnées du coin supérieur gauche de la fenêtre.

Obtenir les tailles- obtient les dimensions de la fenêtre en pixels. Les valeurs sont renvoyées via les paramètres correspondants.

Définir les tailles(Titre de la fenêtre, Largeur, Hauteur) - définit la taille de la fenêtre en pixels.

Fonctions du système :

Obtenir la permission actuelle(Horz, Vert) - obtient la résolution actuelle de l'écran. Les valeurs sont renvoyées via les paramètres correspondants.

GetPermissionList() - obtient une liste des résolutions d'écran disponibles dans le système. Les données sont renvoyées sous la forme « RESOL.1, RESOL.2, RESOL.3... ». Dans le traitement de démonstration, il existe un exemple de génération d'une liste d'autorisations sur un formulaire.

Définir l'autorisation(Résolution d'écran sélectionnée) - définit la résolution de l'écran. Le paramètre spécifie le numéro de série de l'autorisation. Le traitement de démonstration montre un exemple de définition d'une résolution à partir d'une liste générée précédemment.

Bonus:

Sommeil (heure de sommeil) dormir().Le temps de sommeil est indiqué en millisecondes.

Signal (Fréquence, Durée) - implémentation de la fonction classiquebip().Vous permet de définir la fréquence et la durée du son.

Total

La bibliothèque a été écrite pour nos propres besoins et sera probablement développée davantage si nécessaire. Si quelqu'un a une idée brillante pour étendre ses fonctionnalités dans le domaine pour lequel il a été conçu, écrivez vos souhaits. Si les idées s’avèrent valables, elles seront mises en œuvre.

Le kit de livraison comprend : Une base avec un VC connecté sous la forme d'un aménagement général et d'un traitement de démonstration. VK dans l'archive zip.