Détails du formulaire géré (1Cv8). Ajout et modification par programme d'éléments de formulaires gérés Ajout d'attributs à un formulaire géré

La plateforme 1C:Enterprise vous permet d'ajouter et de modifier par programme des éléments d'un formulaire géré. Voyons pourquoi cela pourrait être nécessaire.

Une modification logicielle du formulaire peut être nécessaire dans plusieurs cas :

• Lors de la finalisation des configurations standards pour faciliter la procédure de mise à jour ultérieure. Dans ce cas, seul le module de formulaire sera modifié. Les modules sont beaucoup plus faciles à mettre à jour que les formulaires.
• Lors de la mise en œuvre de certains algorithmes courants. Par exemple, dans le sous-système « Interdiction de modifier les détails de l'objet », un bouton peut être créé par programme pour tous les objets connectés au sous-système afin de permettre la modification des détails.
• Lors de la mise en œuvre de certains algorithmes spécifiques. Par exemple, dans le répertoire Nomenclature, des champs sont créés pour modifier des détails supplémentaires.

Dans un formulaire géré, vous pouvez ajouter, modifier et supprimer par programme :

• conditions requises;
• équipes locales ;
• éléments.

Toutes ces opérations ne sont possibles que sur le serveur.

La refonte programmatique a des limites :

• Vous pouvez uniquement supprimer les détails/commandes/éléments ajoutés par programme. Vous ne pouvez pas supprimer par programme les objets créés dans le configurateur.
• Vous ne pouvez pas attribuer un attribut comme principal.

Modification des commandes de formulaire

Pour gérer la composition des commandes d'un objet Formulaire géré il y a une collection Équipes

Ajouter (< ИмяКоманды >)

Quantité ()

Trouver (< ИмяКоманды >)

Supprimer (< Команда >)

La collection Teams est disponible sur le client et le serveur. Vous pouvez modifier la collection (méthodes Add() et Delete()) uniquement sur le serveur. Vous pouvez rechercher et obtenir le nombre d'éléments (les méthodes Find() et Count()) aussi bien sur le client que sur le serveur.

Comme exemple de travail avec les commandes de formulaire, créons une nouvelle commande ChangeHistory avec l'en-tête "ChangeHistory...", qui appellera le gestionnaire. Afficher l'historique(). La création se produit à l'ouverture du formulaire.

&Sur le serveur
Procédure WhenCreatingOnServer (échec, traitement standard)
Équipe = Équipes. Ajouter( "Histoire des changements");
Équipe . Action = ;
Équipe . Titre = "Histoire des changements...";
Fin de la procédure
&SurClient
Procédure Connectable_DisplayHistory (commande)
// actions de commande
Fin de la procédure

Le gestionnaire de commandes doit être situé sur un formulaire et avoir une directive de compilation &OnClient.

Modification des détails du formulaire

La lecture de la composition des détails du formulaire est effectuée par la fonction Obtenir des détails(< Путь >) renvoyant un tableau de type FormAttributes. Le paramètre function spécifie le chemin d'accès à l'attribut parent (sous forme de chaîne). Si le paramètre est omis ou qu'une chaîne vide est spécifiée, les détails de niveau supérieur sont renvoyés.

La modification des détails se fait à l'aide de la méthode Modifier les détails(<Détails ajoutés>, <Détails amovibles>) objet Formulaire géré. Vers les paramètres Détails ajoutés Et Détails amovibles Des tableaux avec des éléments de type Form Attributes sont transmis.

Attention!

Le processus de modification de la composition des détails nécessite beaucoup de ressources. Le formulaire est en train d'être recréé. À cet égard, le travail avec les détails du formulaire est effectué en mode batch.

Créons un nouvel attribut de formulaire avec le nom Acheteur :

AddedDetails = Nouveau tableau ;
Détails ajoutés. Ajouter (nouveaux attributs de formulaire(« Acheteur », nouvelle description du type (« Lien vers l'annuaire. Contreparties »), « Client » );

// Modifications dans la composition des détails
);

Modification des éléments du formulaire

Pour contrôler la composition des éléments d’un objet Formulaire géré il y a une collection Éléments. La collection dispose de plusieurs méthodes :

Insérer (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Ajouter (< Имя>, < ТипЭлемента>, < Родитель >)

Quantité ()

Trouver (< Имя >)

Se déplacer(< Элемент>, < Родитель>, < МестоРасположения >)

Supprimer (< Элемент >)

La collection Items est disponible sur le client et le serveur. Modifier une collection (Insérer des méthodes () , Add () , Move () et Delete () ) ne sont disponibles que sur le serveur. Vous pouvez rechercher et obtenir le nombre d'éléments (les méthodes Find() et Count()) aussi bien sur le client que sur le serveur. Les éléments de collection peuvent être :

• Groupe de formulaires ;
• FormTable ;
• Champ de formulaire ;
• Bouton de formulaire.

Vous pouvez affecter par programme des gestionnaires d’événements aux éléments de formulaire. La méthode est destinée à ces fins DéfinirAction(< ИмяСобытия>, < Действие >) .

Examinons quelques-uns des exemples pratiques les plus courants de travail avec des commandes, des détails et des éléments de formulaire.

Ajout d'une commande et de son bouton associé :

// Crée une commande
Équipe = Équipes. Ajouter( "Histoire des changements");
Équipe . Action = "Plug-in_DisplayHistory"; // Le formulaire doit contenir une procédure avec le nom spécifié
Équipe . Titre = "Histoire des changements...";
// Crée un bouton et associe-le à une commande
Élément = Articles. Ajouter( "Histoire des changements", Tapez("FormButton" ));
Élément.CommandName = "Histoire des changements";

Ajout d'un attribut et du champ de saisie associé :

// Description des détails ajoutés
AddedDetails = Nouveau tableau ;
Détails ajoutés. Ajouter(Nouveaux accessoires de formulaire (« Acheteur », nouvelle description de type ( "DirectoryLink. Contreparties"), "Client" ));
// Modification de la composition des détails
ChangeDetails (Détails ajoutés);
// Création d'un champ de saisie et connexion à l'attribut
Élément = Articles. Ajouter("Acheteur" , Type("FormField" ));
Élément . Vue = FormFieldView. Champ de saisie ;
Élément . CheminVersDonnées= "Acheteur" ;

Affectation d'un gestionnaire d'événements à un élément de formulaire :

ArticleClient. DéfinirAction("Quand ça change" , "Connecté_AcheteurOnChange");

&SurClient
Procédure Connecté_AcheteurOnChange(Élément)
//Actions d'événement
Fin de la procédure

Attention!

Procédures définies comme gestionnaires d'événements à partir du code à l'aide de la méthode DéfinirAction(), il est recommandé de définir le préfixe Connectable_.

Attention!

Vous pouvez télécharger un traitement avec des exemples de recherche programmatique et de modification des détails, des commandes et des éléments d'un formulaire géré.

Détails du formulaire

Un ensemble de détails du formulaire décrit la composition des données affichées, modifiées ou stockées dans le formulaire. Dans le même temps, les détails du formulaire eux-mêmes n'offrent pas la possibilité d'afficher et de modifier des données. Les éléments de formulaire (voir la section « Éléments de formulaire » de ce chapitre) associés aux détails du formulaire sont utilisés pour l'affichage et l'édition. L’ensemble de tous les détails du formulaire sera appelé données du formulaire.

Important! Il ne faut pas oublier que, contrairement aux formulaires classiques, toutes les données d'un formulaire géré doivent être décrites sous forme de détails. Il n'est pas autorisé d'utiliser des variables de module de formulaire comme sources de données pour les éléments de formulaire.

Il est possible d'attribuer Détails du formulaire de base, c'est-à-dire les attributs qui détermineront la fonctionnalité standard du formulaire (extension de formulaire). Il faut rappeler qu’un formulaire ne peut avoir qu’un seul attribut principal.

Extension de formulaire– ce sont des propriétés, méthodes et paramètres de formulaire supplémentaires de l’objet ManagedForm, caractéristiques de l’objet qui est l’élément principal du formulaire.

Au cours du processus de développement du formulaire, vous pouvez définir explicitement la possibilité d'afficher et de modifier des détails spécifiques du formulaire, en termes de rôles, à l'aide des propriétés Afficher et Modifier (pour plus de détails, consultez la section « Paramètres du formulaire basé sur les rôles » de la section « Éditeurs). " chapitre). De plus, la disponibilité d'un attribut particulier dans le formulaire lui-même peut être configurée à l'aide d'options fonctionnelles (plus de détails sur les options fonctionnelles peuvent être trouvées dans le chapitre « Gestion de l'interface de configuration »).

Propriété d'attribut de formulaire Données enregistrées est un signe qu'une modification interactive des détails entraînera une tentative de blocage des données du formulaire pour l'édition, ainsi qu'au réglage automatique de l'indicateur de modification du formulaire.

Types de données disponibles dans un formulaire géré

Un formulaire géré diffère également d’un formulaire standard par les types de données avec lesquels il fonctionne. Si le formulaire normal fonctionne avec la plupart des types fournis par 1C:Enterprise (y compris les types DirectoryObject, DocumentObject, etc.), alors dans le formulaire géré, les catégories de types suivantes peuvent être distinguées :

• les types directement utilisés dans le formulaire sont les types qui existent du côté du client léger et du client Web (par exemple, Number, DirectoryLink.Products, GraphicScheme, TabularDocument) ;

• types qui seront convertis en types de données spéciaux : types de données de formulaire gérés. Ces types sont affichés dans la liste des détails du formulaire entre parenthèses, par exemple (DirectoryObject.Products) ;

• liste dynamique (pour plus de détails, voir la section « Liste dynamique » de ce chapitre).

Conversion d'objets d'application en données de formulaire

Certains types d'applications (comme DirectoryObject, etc.) n'existent pas côté client léger et Web (voir le chapitre Concept d'application gérée pour plus de détails). Par conséquent, pour représenter ces types d’applications dans le formulaire, la plateforme a introduit des types de données spéciaux conçus pour fonctionner dans des formulaires gérés. Cette fonctionnalité d'une application gérée nécessite de convertir les objets d'application en données de formulaire (et vice versa).

Les types de données suivants sont utilisés :

• Form DataStructure – contient un ensemble de propriétés d’un type arbitraire. Les propriétés peuvent être d'autres structures, des collections ou des structures avec des collections. Ce type est représenté, par exemple, sous la forme DirectoryObject.

• Un FormDataCollection est une liste de valeurs saisies, semblable à un tableau. Un élément de collection est accessible par index ou identifiant. L'accès par pièce d'identité peut ne pas être disponible dans certains cas. Cela est dû au type d’objet d’application représenté par cette collection. L'identifiant peut être n'importe quel nombre entier. Ce type est représenté par exemple sous la forme d'une partie tabulaire.

• Form DataStructureWithCollection est un objet qui est représenté à la fois comme une structure et une collection. Elle peut être traitée comme n’importe laquelle de ces entités. Ce type représente, par exemple, un ensemble d'enregistrements dans un formulaire.

• Form DataTree – un objet conçu pour stocker des données hiérarchiques.

Un objet d'application est représenté par un ou plusieurs éléments de données de formulaire. En général, la hiérarchie et la composition des données du formulaire dépendent de la complexité et de l'interconnexion des objets d'application du formulaire géré.

Par exemple, un document contenant une partie tabulaire sera représenté par un objet de type FormDataStructure (le document lui-même), auquel est subordonné un objet de type FormDataCollection (partie tabulaire du document).

Important! Lors du développement d'une configuration, il est important de se rappeler que les objets d'application sont disponibles uniquement sur le serveur, tandis que les objets de données de formulaire peuvent être utilisés à la fois sur le serveur et sur le client.

Transmission de données entre les parties client et serveur d'un formulaire géré

En fait, on peut dire que les données du formulaire sont une représentation unifiée des données de divers objets d'application avec lesquels le formulaire fonctionne de manière uniforme et qui sont présents à la fois sur le serveur et sur le client. Autrement dit, le formulaire contient une certaine « projection » des données de l'objet d'application sous la forme de ses propres types de données et effectue une conversion entre eux si nécessaire. Cependant, si le développeur de configuration implémente son propre algorithme de traitement des données, il doit alors effectuer la conversion des données (des types spécialisés vers les types d'application et vice versa) de manière indépendante.

Lors de l'édition des détails du formulaire dans un éditeur spécialisé (pour plus de détails, voir la section « Détails du formulaire » du chapitre « Éditeurs »), il est possible d'influencer le transfert de données entre le client et le serveur lors de l'exécution du formulaire. La colonne de l'éditeur de détails est utilisée à cet effet. Utilisez toujours. L'effet de cette propriété diffère pour trois types d'attributs :

• Pour un attribut subordonné à une liste dynamique (colonne de liste dynamique) :
  • propriété activée – l'attribut est toujours lu dans la base de données et inclus dans les données du formulaire ;
  • La propriété est désactivée : l'attribut est lu dans la base de données et inclus dans les données du formulaire uniquement lorsqu'il existe un élément de formulaire actuellement visible associé à l'attribut ou à son attribut subordonné.

• Pour les accessoires subordonnés à la collection de mouvements :
  • la propriété est activée – les mouvements de documents sont lus à partir de la base de données et seront présents dans les données du formulaire ;
  • La propriété est désactivée - les mouvements de documents ne seront pas lus dans la base de données et ne seront pas inclus dans les données du formulaire (s'il n'y a aucun élément de formulaire faisant référence aux mouvements de documents).

• Autres détails du formulaire :
  • la propriété est activée – l'attribut sera présent dans les données du formulaire, qu'il y ait ou non au moins un élément de formulaire associé à l'attribut ou à son attribut subordonné ;
  • La propriété est désactivée - l'attribut sera présent dans les données du formulaire uniquement s'il existe un élément de formulaire associé à l'attribut ou à son attribut subordonné. Contrairement aux attributs de liste dynamique, la visibilité de l'élément associé à l'attribut n'a pas d'importance ici.

Note. Il ne faut pas oublier que la propriété définie sur l'attribut parent affecte tous les attributs subordonnés. Par exemple, si la propriété Utiliser est toujours effacée pour la partie tabulaire du document, alors le système considère que cette propriété est également effacée pour tous les détails subordonnés (malgré l'état réel de la propriété).

Méthodes de conversion des données d'objet d'application en données de formulaire

Pour convertir des objets d'application en données de formulaire et inversement, il existe un ensemble de méthodes globales :

• ValueInFormData(),
• FormDataInValue(),
• CopierFormData().

Important! Les méthodes qui fonctionnent avec les objets d'application sont disponibles uniquement dans les procédures serveur. La méthode de copie des valeurs entre les données du formulaire est disponible sur le serveur et sur le client, car elle ne nécessite pas d'objets d'application comme paramètres.

Lors de la conversion des données d'un formulaire en objet d'application, vous devez tenir compte de leur compatibilité.

• ValueInFormData() – convertit un objet de type application en données de formulaire ;
• FormDataInValue() – convertit les données du formulaire en un objet de type application ;
• CopyFormData() – copie les données du formulaire qui ont une structure compatible. Renvoie True si la copie a réussi ou False si la structure de l'objet est incompatible.

Note. Lors de l'exécution d'actions standards (ouverture d'un formulaire, exécution d'une commande d'écriture standard, etc.) d'un formulaire avec les principaux détails, la conversion est effectuée automatiquement.

Donnons un exemple de la façon d'utiliser la transformation des données dans vos propres algorithmes.

&OnServerProcedure lorsque CreateOnServer (échec, traitement standard)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData (ObjectItem, Objet);

Fin de la procédure

&OnClient Procédure Write()

WriteOnServer();

Fin de la procédure

&OnServer Procédure WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Fin de la procédure

L'objet ManagedForm dispose également de méthodes disponibles sur le serveur :

• ValueВFormAttribute() – convertit un objet de type d'application en l'attribut de formulaire spécifié.
• FormAttributeVValue() – convertit un attribut de données de formulaire en un objet d'un type d'application.

L'utilisation de ces méthodes est généralement plus pratique, car elles contiennent, par exemple, des informations sur le type de détails du formulaire. De plus, la méthode Form AttributesValue() définit la correspondance entre les données du formulaire et l'objet, qui est utilisé lors de la génération des messages. Vous pouvez en savoir plus à ce sujet dans le chapitre « Capacités de navigation des services ».

Donnons un exemple d'utilisation de ces méthodes.

&OnServer Procédure RecalculateOnServer()

// Convertit l'attribut Object en un objet d'application. Document = Formulaire AttributesValue("Objet"); // Effectue un recalcul en utilisant la méthode définie dans le module document. Document.Recalculate(); // Convertit l'objet d'application en accessoire. ValueВFormAttributes (Document, "Objet");

Fin de la procédure

Interface logicielle

Arbre de données de formulaire

• RechercherParId
• Obtenir des éléments

Description:

Conçu pour modéliser une arborescence dans des données de formulaire gérées.

Cet objet peut être sérialisé vers/depuis XDTO. Le type XDTO correspondant à un objet donné est défini dans l'espace de noms. Nom du type XDTO :

Obtenir des éléments

Syntaxe:

Obtenir des éléments()

Valeur de retour :

Type : Collection de données de formulaire d'éléments d'arborescence.

Description:

Obtient une collection d’éléments d’arborescence de niveau supérieur.

Disponibilité : client, serveur, client léger, client web.

RechercherParId

Syntaxe:

RechercherParId(<Идентификатор>)

Possibilités :

<Идентификатор>(requis)

Tapez : Numéro. Identificateur d’élément d’arbre.

Valeur de retour :

Tapez : FormDataTreeElement.

Description:

Obtient un élément de collection par ID.

Disponibilité : client, serveur, client léger, client web.

FormDataTreeItem

Propriétés:

<Имя свойства> (<Имя свойства>)

• Obtenir un identifiant (Obtenir un identifiant)
• ObtenirParent
• Obtenir des éléments
• Propriété

Description:

Élément d’arborescence de données de formulaire.

FormDataTreeItemCollection

Éléments de collection : DataFormTreeElement

Pour un objet, il est possible de parcourir la collection à l'aide de l'opérateur For each... From... Loop. Le parcours sélectionne les éléments de la collection. Il est possible d'accéder à un élément de collection à l'aide de l'opérateur [...]. L'index de l'élément est passé en argument.

• Insérer
• Ajouter
• Index (IndexDe)
• Compter
• Clair
• Obtenir
• Se déplacer
• Supprimer

Description:

Collection d'éléments en bois.

Disponibilité : client, serveur, client léger, client web.

Voir également:

• FormDataTreeElement, méthode GetElements
• DataFormTree, méthode GetItems

Caractéristiques du travail avec un arbre de valeurs

Mise à jour de l'arborescence

Il ya un problème chutes plates-formes lors de la mise à jour de l'arborescence.

Si un nœud de l'arborescence a été développé et qu'un nœud subordonné a été sélectionné, alors lors de la mise à jour de l'arborescence avec la fonction ValueInFormData la plate-forme tombe.

Solution : Vous devez effacer l'arborescence avant la mise à jour.

Par exemple:

&Sur la procédure serveur ClearTree(elements) Pour chaque élément des éléments Loop ClearTree(element.GetElements()); Fin du cycle ; éléments.Clear(); Fin de la procédure

&Sur la procédure du serveur, remplissez l'arbre conceptuel() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Fin de la procédure

&OnClient Procédure OnDateOnChange(Element) Fill ConceptTree(); Fin de la procédure

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

Introduction

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

• 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 ne sont pas disponibles 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.

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

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

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 des 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 ?

• 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.

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

• 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)

• … 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

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

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

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 « grossière » sont utilisés :

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

Structurer le code

• 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, répétons-le, toutes les méthodes du serveur ne peuvent pas être appelées depuis le client et, 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.

• 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 le Serveur Procédure lors de sa création sur le Serveur (Échec, 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

• 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.

Le formulaire est contrôlé par divers éléments de formulaire, situés hiérarchiquement sur l'onglet Éléments concepteur de formulaires. L'élément le plus important est la forme elle-même, qui se situe au sommet de la hiérarchie des éléments, et les éléments restants lui sont subordonnés.

Tous les éléments du formulaire peuvent être divisés en cinq groupes : champs, éléments de regroupement, boutons, décorations et tableaux. Dans mes articles, j'analyserai chacun des groupes. Dans cet article, nous commencerons à étudier l'un des types d'éléments de champ - champ de saisie, mais avant cela, nous apprendrons comment ajouter un élément au formulaire.

Ajouter des éléments à un formulaire

Cela se fait tout simplement : il faut sélectionner l'élément Formulaire dans la fenêtre Éléments de conception de formulaire et cliquez sur le bouton « Ajouter ». Après cela, une fenêtre s'ouvrira dans laquelle vous devrez sélectionner le type d'élément souhaité

Après sélection, l'élément souhaité apparaîtra dans la fenêtre Éléments.

Élément de formulaire géré Champ

Regardons un élément de formulaire géré Champ. Cet élément est nécessaire pour saisir des informations sur le formulaire. Et aussi pour afficher toute information. Après avoir ajouté cet élément au formulaire, la palette des propriétés de l'élément de formulaire s'ouvrira sur la droite. Pour l’instant, vous devriez être intéressé par deux propriétés : DataPath et View.

Dans la propriété DataPath, le développeur peut associer un élément de formulaire à l'attribut de formulaire souhaité. Veuillez noter qu'une fois l'élément ajouté Champ de saisie sur le formulaire, il n'était pas affiché sur le formulaire lui-même. Cela s'est produit parce que notre nouvel élément n'est pas associé à . Par exemple, j'ai créé plusieurs attributs sur le formulaire de traitement avec différents types primitifs et un attribut avec un type référence.

Connectons maintenant notre élément de formulaire récemment ajouté à l'un des détails ; pour ce faire, sélectionnez l'attribut souhaité dans la propriété PathKData de l'élément.

Après cela, les propriétés DataPath et View seront renseignées et l'élément lui-même sera affiché dans la vue formulaire.

Faites attention à la propriété de l'élément Voir. Cette propriété définit la fonctionnalité du champ de saisie. Vous pouvez sélectionner différentes valeurs pour cette propriété.

En fonction de la valeur sélectionnée, la fonctionnalité sera déterminée. Dans les images ci-dessus, la valeur sélectionnée est – champ de saisie, c'est à dire. nous pouvons saisir n'importe quelle valeur dans ce champ de saisie, et si nous sélectionnons une valeur champ d'étiquette, alors nous ne pourrons rien saisir.

La valeur de cette propriété Voir Les champs de saisie sont pratiques à sélectionner lorsque vous avez simplement besoin d'afficher des informations d'aide à l'utilisateur.

Ajoutons maintenant un nouvel élément de formulaire avec le type Champ de saisie et connectez-le avec les accessoires DétailsDate via la propriété DataPath qui nous est déjà familière

Comme vous pouvez le constater, l'apparence du champ de saisie a changé, et le choix possible des valeurs pour la propriété View va également changer.

Ainsi, nous concluons que la fonctionnalité du champ de saisie dépend du type d'attribut.

Pour les accessoires avec type Booléen Les valeurs de propriété View suivantes seront disponibles.

Et pour les attributs avec un type référence, d'autres valeurs de la propriété View seront disponibles.

Un travail plus détaillé avec des éléments de formulaire à l'aide d'exemples pratiques est donné dans le livre « Bases du développement en 1C : Taxi. Développement d'applications gérées en 12 étapes".

Parfois, il semble qu'apprendre le langage de programmation en 1C soit compliqué et difficile. En fait, la programmation en 1C est simple. Mes livres vous aideront à maîtriser rapidement et facilement la programmation en 1C : et « Les bases du développement en 1C : Taxi »

Apprenez la programmation en 1C à l'aide de mon livre « Programmation en 1C en 11 étapes »

1. Pas de termes techniques compliqués.
2. Plus de 700 pages de matériel pratique.
3. Chaque tâche est accompagnée d'un dessin (capture d'écran).
4. Une collection de problèmes pour les devoirs.
5. Le livre est écrit dans un langage clair et simple – pour un débutant.

Ce livre convient à ceux qui ont déjà commencé à programmer et rencontrent certaines difficultés avec ce sujet et à ceux qui programment depuis longtemps, mais n'ont jamais travaillé avec les formulaires gérés 1C.

1. Sans termes techniques complexes ;
2. Plus de 600 pages de matériel pratique ;
3. Chaque exemple est accompagné d'un dessin (capture d'écran) ;
4. Le livre est envoyé par email au format PDF. Peut être ouvert sur n’importe quel appareil !

Code promo pour une réduction de 15% - 48PVXHeYu

Si cette leçon vous a aidé à résoudre un problème, que vous l'avez aimé ou que vous l'avez trouvée utile, alors vous pouvez soutenir mon projet en faisant un don de n'importe quel montant :

Vous pouvez payer manuellement :

Yandex.Argent - 410012882996301
Argent Web - R955262494655

Rejoignez mes groupes.