Que sont les modules et à quoi servent-ils exactement ? Le module contient le code du programme. De plus, il convient de noter que, contrairement à la plateforme 7.7, où le code pouvait être situé dans les propriétés des éléments de formulaire et dans les cellules des tableaux de mise en page, dans la plateforme 8.x, toute ligne de code doit être située dans un module. . En règle générale, un module se compose de trois sections : une section pour décrire les variables, une section pour décrire les procédures et les fonctions et une section pour le programme principal. Cette structure est typique de presque tous les modules de la plateforme, à quelques exceptions près. Certains modules n'ont pas de section de description des variables ni de section de programme principal. Par exemple, module de session et tout module général.

Le contexte d'exécution des modules est généralement divisé en client et serveur. De plus, certains modules peuvent être compilés aussi bien côté client que côté serveur. Et certains sont exclusivement côté serveur ou côté client. Donc:

Module applicatif

Le module est conçu pour capturer les moments de lancement de l'application (chargement de la configuration) et de fin de son fonctionnement. Et les procédures de vérification peuvent être placées dans les événements correspondants. Par exemple, lors du démarrage d'une application, mettez à jour certaines données de configuration de référence et, une fois le travail terminé, demandez si cela vaut la peine de la quitter, peut-être que la journée de travail n'est pas encore terminée. De plus, il intercepte les événements provenant d'équipements externes, par exemple commerciaux ou fiscaux. Il est à noter que le module applicatif n'intercepte les événements décrits que lorsqu'il est lancé de manière interactive. Ceux. lorsque la fenêtre du programme elle-même est créée. Cela ne se produit pas si l'application est lancée en mode connexion com.

Il existe deux modules d'application différents dans la plateforme 8.2. Il s’agit du module Application régulière et du module Application gérée. Ils sont déclenchés au lancement de différents clients. C'est ainsi que le module d'application gérée est déclenché lorsque le client web, le client léger et le client lourd sont lancés en mode application gérée. Et le module d'application standard est déclenché lorsque le client lourd est lancé en mode application normal.

Un module d'application peut contenir toutes les sections - descriptions des variables, procédures et fonctions, ainsi que des descriptions du programme principal. Le module applicatif est compilé côté client, cela nous limite donc grandement dans la disponibilité de nombreux types de données. Vous pouvez étendre le contexte du module d'application à l'aide de méthodes de modules communs dont la propriété « Appel au serveur » est définie. Toutes les variables et méthodes marquées comme exportées seront disponibles dans n'importe quel module de configuration exécuté côté client. Cependant, aussi tentant que cela puisse être, vous ne devriez pas publier ici un grand nombre de méthodes. Plus il contient de code, plus le temps de compilation est long, et donc le temps de lancement de l'application, ce qui est très gênant pour les utilisateurs.

Comme indiqué ci-dessus, le module d'application gère les événements de démarrage et de fin d'application. Pour gérer chacun de ces événements dans le module d'application, il existe une paire de gestionnaires Avant... et Quand... Les différences entre eux sont telles que lors de l'exécution du code dans le gestionnaire Avant..., l'action n'a pas encore a eu lieu et nous pouvons refuser de l'exécuter. C'est à cela que sert l'option Rejeter. Dans les gestionnaires On.., l'action a déjà eu lieu, et on ne peut pas refuser de lancer l'application ou d'en sortir.

Module de connexion externe

L'objectif du module est similaire à celui du module d'application. Il traite les points de début et de fin de l'application. Le module de connexion externe se déclenche au lancement de l'application en mode connexion com. Le processus de jointure externe lui-même est un processus non interactif. Dans ce mode, le travail programmatique avec la base d'informations se produit et la fenêtre de l'application ne s'ouvre pas, ce qui impose certaines restrictions sur l'utilisation de méthodes destinées au travail interactif. Dans ce mode, les appels aux formulaires de dialogue, les messages d'avertissement, etc. ne peuvent pas être utilisés. Ils ne fonctionneront tout simplement pas.

Comme dans le module d'application, des sections de description des variables, des méthodes et une section pour le programme principal sont disponibles ici. Vous pouvez également déclarer des variables et des méthodes d'exportation. La différence est qu'en mode de connexion COM, tout le travail avec l'infobase s'effectue côté serveur, de sorte que le module de connexion externe est compilé exclusivement sur le serveur. Par conséquent, les variables d'exportation et les méthodes des modules clients courants n'y sont pas disponibles.

Module de séance

Il s'agit d'un module hautement spécialisé destiné uniquement à initialiser les paramètres de session. Pourquoi avez-vous dû créer votre propre module pour cela ? Cela est dû au fait que le processus d'initialisation peut nécessiter l'exécution d'un certain code, et en plus, l'application peut être lancée sous différents clients (ce qui conduit à l'exécution de différents modules applicatifs ou d'un module de connexion externe), et l'initialisation de les paramètres de session doivent être définis dans n’importe quel mode de lancement. Par conséquent, un module supplémentaire était nécessaire pour fonctionner dans n'importe quel mode de lancement d'application.

Dans le module de session, il existe un seul événement « SettingSessionParameters », qui est exécuté en premier, avant même l'événement du module d'application BeforeSystemStartOperation. La section de déclaration de variable et la section du programme principal n'y sont pas disponibles. Vous ne pouvez pas non plus déclarer de méthodes d'exportation. Le module est compilé côté serveur.

Il ne faut pas être tenté par le fait que ce module est exécuté à chaque lancement de l'application, et il ne faut pas y placer de code qui n'est pas directement lié à l'initialisation des paramètres de session. Cela est dû au fait que le gestionnaire SetSessionParameters peut être appelé à plusieurs reprises pendant le fonctionnement du système. Par exemple, cela se produit dans les cas où nous accédons à des paramètres non initialisés. Et bien qu'il soit possible de capter le moment du premier lancement de cet événement (RequiredParameters est de type Undefined), il faut tenir compte du fait que ce module est compilé en mode privilégié, c'est-à-dire il ne contrôle pas les droits d'accès. Et le deuxième point est que nous ne pouvons toujours pas être sûrs à cent pour cent que le système sera lancé. Soudain, une panne se produit dans le module d'application et nous essayons d'effectuer certaines actions avec la base de données.

Modules communs

Les modules sont destinés à décrire certains algorithmes courants qui seront appelés à partir d'autres modules de configuration. Le module général ne contient pas de section de description des variables ni de section de programme principal. Vous pouvez y déclarer des méthodes d'exportation dont le contexte d'accessibilité sera déterminé par des indicateurs de compilation. En raison du fait que la section de description des variables n'est pas disponible, les variables globales ne peuvent pas être définies dans les modules communs. Pour ce faire, vous devez utiliser les fonctions de modules communs avec mise en cache des valeurs de retour ou un module applicatif. Il convient de garder à l'esprit que même si la propriété de réutilisation du module partagé est définie sur « Pour la durée de la session », alors dans ce cas, la durée de vie des valeurs mises en cache ne dépasse pas 20 minutes à partir du moment du dernier accès à eux.
Le comportement d'un module commun dépend des paramètres définis (globaux ou non, divers drapeaux de compilation, disponibilité d'un appel serveur, etc.). Dans cet article, nous n'examinerons pas tous les types de paramètres, ainsi que les caractéristiques comportementales et les pièges qui surviennent lors de la définition déraisonnable d'indicateurs de propriété. Il s'agit d'un sujet pour un article séparé. Attardons-nous sur quelques points à suivre lors de la définition des drapeaux :

• Une bonne règle de base est de ne pas utiliser le drapeau mondial partout. Cela réduira le temps de démarrage de l'application, et améliorera également la lisibilité du code (bien sûr, si le module commun a un nom tout à fait significatif).
• Il n'est pas conseillé d'utiliser plus d'un indicateur de compilation. Il n'y a pas beaucoup de méthodes qui doivent être exécutées dans différents contextes, et si de telles méthodes sont toujours nécessaires, un module commun distinct peut leur être alloué.
• Le flag "Server Call" n'a de sens que si le module est compilé "Sur le serveur". Par conséquent, tous les autres indicateurs de compilation doivent être supprimés pour éviter divers problèmes.
• Si les méthodes du module impliquent un traitement massif de données, une lecture et une écriture dans la base de données, alors pour augmenter la vitesse de travail, il est préférable de désactiver le contrôle des droits d'accès en définissant l'indicateur « Privilégié ». Ce mode n'est disponible que pour les modules partagés compilés sur le serveur.

Module de formulaire

Il est conçu pour traiter les actions des utilisateurs, c'est-à-dire divers événements liés à la saisie des données et au traitement de l'exactitude de leur saisie. Un module de forme habituelle est compilé entièrement sur le client. Un module de formulaire géré est clairement délimité par le contexte d'exécution, donc toutes les variables et méthodes doivent avoir une directive de compilation. Si la directive n'est pas explicitement spécifiée, alors cette variable ou méthode sera compilée côté serveur. Le module de formulaire contient des sections pour les descriptions des variables et des méthodes, ainsi qu'une section pour le programme principal.

Module objet

Ce module est typique de nombreux objets de configuration et est généralement destiné au traitement des événements d'objet. Par exemple, des événements d'enregistrement et de suppression d'objets, des événements de publication de documents, etc.

Certains événements de module objet dupliquent les événements du module de formulaire. Par exemple, les événements associés à un enregistrement. Cependant, sachez que les événements du module de formulaire seront exécutés exclusivement sur le formulaire spécifique de l'objet. En général, il peut y avoir plusieurs de ces formes. Et les événements du module objet seront appelés dans tous les cas, même au moment du travail de programmation avec l'objet. Par conséquent, si vous devez exécuter du code dans tous les cas, il est préférable d'utiliser un événement de module objet pour cela.

Le module objet est compilé exclusivement sur le serveur. Vous pouvez y définir des variables et des méthodes d'exportation qui seront disponibles dans d'autres modules de configuration. En utilisant ces propriétés et méthodes, nous pouvons étendre considérablement les fonctionnalités de l'objet.

Module gestionnaire d'objets

Ce module existe pour de nombreux objets de configuration. L'objectif principal de ce module est de redéfinir l'événement de sélection standard qui se produit lors de la saisie d'une ligne et d'étendre les fonctionnalités du gestionnaire. Le module est compilé côté serveur. Il vous permet de définir les propriétés et les méthodes d'exportation. L'appel des méthodes d'export du gestionnaire ne nécessite pas de créer l'objet lui-même.

À tout ce qui précède, vous pouvez ajouter une image de certains modules de configuration et des méthodes d'appel mutuel des méthodes en mode application gérée. La flèche indique la direction dans laquelle vous pouvez vous tourner pour appeler la méthode correspondante. Comme le montre le diagramme, le contexte du serveur est complètement fermé. Mais depuis le contexte client il est possible d’accéder aux méthodes serveur.

Symboles sur le schéma : O.M. Client - Module commun client ; O.M. Serveur - Module partagé du serveur ; M.F. Client - Procédures client du module de formulaire ; M.F. Serveur - Procédures serveur du module de formulaire.

Salut tout le monde.
Aujourd'hui, nous allons regarder modules de la plateforme 1C Enterprise 8.2, il y en a plus que dans la version 8.1 et parfois ce n'est pas si simple de s'en rendre compte.
Exemple:

Si vous regardez l'aide de 1C, vous verrez la définition suivante du Module :
Un module est un programme écrit dans le langage intégré du système 1C:Enterprise.

Et pour faire simple : B Modules 1C contient du code exécutable nécessaire pour répondre d'une manière ou d'une autre aux actions du système ou de l'utilisateur lorsque les moyens visuels ne suffisent pas pour décrire l'interaction des objets dans le configurateur. Vous pouvez également décrire vos propres méthodes dans les modules du programme.

Toute ligne de code se trouve dans un module, contrairement à 1C7.7, où le code du programme pouvait être situé dans les cellules des tableaux de mise en page et dans les propriétés des éléments de formulaire.

Listons les modules qui sont dans 1C 8.2

Modules de plateforme 1C Entreprise 8.2:

Module d'application géré
Module de candidature régulier
Module de connexion externe
Module de séance
Modules communs
Module objet
Module de formulaire
Module gestionnaire d'objets
Module gestionnaire de valeur
Modules de jeu d'enregistrements

Principales sections du module :
1. Section de description des variables locales de ce module, vous pouvez spécifier une directive de compilation (n'existe pas pour tous les modules).
2. Section décrivant les procédures et les fonctions. Si vous n'écrivez pas de directive de compilation, alors par défaut il s'agit de &OnServer, l'ordre des procédures et des fonctions n'a aucune importance.
3. Section du programme principal du module (contient quelques instructions). Cette section est exécutée lors de l'accès à un module (n'existe pas pour tous les modules).

Tous les modules ne contiennent pas de sections de description de variables et une section de programme principal.
Par exemple : module Général ou module Session.

Règles de compilation des modules :
1. Certains modules sont entièrement compilés soit côté client, soit côté serveur. Toutes les méthodes qu'ils contiennent sont client ou serveur. Un exemple de module client est un module d'application géré.
2. Certains modules peuvent combiner des méthodes client et serveur. Dans ce cas, pour chaque méthode, il est nécessaire de spécifier les directives de compilation - &OnClient ou &OnServer. Un exemple est celui des modules de formulaires gérés.

Classement des modules :
1. Serveur. Compilé uniquement côté serveur - module objet, module gestionnaire, module jeu d'enregistrements.
2. Cliente. Compilé uniquement sur le client, tel qu'un module d'application géré.
3. Combiné. Peut être compilé à la fois sur le serveur et sur le client - le module de formulaire et les modules généraux.

Emplacement de compilation des modules :
1. Client léger (offre la possibilité d'utiliser un navigateur Web).
2. Serveur.
3. Gros client.

Comme vous pouvez le constater, il n'y a pas si peu de modules ; presque tous les objets de configuration ont un module qui a son propre objectif.

Le but de chaque module 1C 8.2

Garde: Vous envisagez d’acheter 1C Enterprise et vous ne savez pas auprès de qui ? La société LBS fait partie du top 20 1C : Franchisés. Engagé dans l'automatisation comptable basée sur les produits 1C. Achetez des produits 1C auprès de LBS et bénéficiez d'une assistance et d'un service 1C de haute qualité.

P.S. Riez de la blague de Loukachenko))

Tout programme est constitué d'un code de programme, c'est-à-dire d'une séquence d'actions écrites dans n'importe quel langage qui doivent être exécutées.

Cependant, ce programme même doit être écrit quelque part, c'est-à-dire situé quelque part. Dans la plupart des cas, le code du programme est écrit dans des fichiers texte brut. La seule différence est que leur extension n'est pas .txt, mais .cpp ou .php.

Où est écrit le programme 1C ?

Qu'est-ce que le module 1C ?

Bien entendu, le code 1C pourrait également être écrit dans un fichier texte. Cependant, il existe le concept de configuration 1C - qui comprend non seulement une liste de paramètres, des modèles de formulaires, etc., mais également le code du programme 1C. Par conséquent, le code 1C est stocké dans la configuration.

La configuration se compose d'objets 1C, comme nous l'avons déjà évoqué dans les leçons précédentes. Chaque objet 1C contient des objets imbriqués, par exemple, un répertoire a plusieurs formes.

Chaque objet 1C, y compris certains objets imbriqués, possède son propre module - un fichier texte contenant le code du programme.

Il existe également des modules indépendants des objets dans lesquels du code de programme peut être écrit indépendamment d'un objet spécifique.

Ainsi, dans 1C, il n'y a pas de programme « unique ». Il existe un ensemble de modules pour écrire du code de programme pour chaque objet de configuration 1C.

Comment les modules 1C sont-ils utilisés ?

L'ensemble du programme peut être grossièrement divisé en deux types :

• Méthode objet
• Réaction aux événements.

Méthodes. Comme nous l'avons dit plus tôt, un objet 1C est une structure intégrale qui comprend à la fois des données et des méthodes pour les traiter. Ces méthodes sont un ensemble d'actions (méthodes) qui peuvent être appelées pour traiter des données. Un exemple d'une telle action est DirectoryObject.Write() – écrit un élément de répertoire dans la base de données.

Les méthodes de nombreux objets 1C peuvent être standard (c'est-à-dire programmées dans la plateforme 1C) et écrites par un programmeur dans le langage 1C. Avec l'aide du second, vous pouvez étendre les fonctionnalités des objets 1C à votre guise.

Événements. Les événements sont disponibles dans de nombreux autres outils de développement. Le but du programme n'est pas seulement de calculer quelque chose au démarrage, mais aussi de soutenir le travail de l'utilisateur.

Événement utilisateur : l'utilisateur a appuyé sur un bouton. En réponse, une partie du code sera exécutée, réagissant aux actions de l'utilisateur.

Événements système - nous avons enregistré l'objet 1C dans la base de données. L'événement système « Write object » s'est produit. Il est possible de configurer une réaction qui se produira aux événements provoqués non pas par l'utilisateur (qui a appuyé sur un bouton ou fait autre chose), mais par le système lui-même. Un exemple frappant d’un tel événement est le démarrage du programme.

L'ordre d'exécution des modules 1C

De nombreuses langues ont un concept tel que « point d'entrée ». Il s'agit de la toute première ligne ou fonction qui sera exécutée au démarrage du programme.

Dans 1C, il existe plusieurs points d'entrée de ce type - pour chaque type de client. Autrement dit, lors du démarrage d'un client lourd, il existe un point d'entrée, lors du démarrage d'un client léger, un autre. Cela vous permet de programmer des fonctionnalités différentes pour différents types de clients.

Le point d'entrée dans le module correspondant est respectivement les gestionnaires d'événements système BeforeSystemStart() et WhenSystemStart() (c'est-à-dire dans l'ordre). Ces fonctions sont exécutées en premier, elles peuvent démarrer quelque chose automatiquement.

Si rien n'a été lancé automatiquement, alors l'interface 1C s'ouvre devant l'utilisateur et alors tout en dépend. Il appuie sur un bouton – le gestionnaire de clic de bouton est exécuté (qui à son tour peut également lancer quelque chose automatiquement).

Travailler avec les modules 1C

Réalisé dans le configurateur. Vous pouvez ouvrir le module à l'aide de la fenêtre Configuration.

Presque tous les objets de configuration ont un module gestionnaire, et pour la plupart des objets un module objet. Souvent, les programmeurs débutants ne comprennent pas les différences entre les objectifs de ces deux modules.

Comprendre la différence dans leur objectif vous permet d'écrire un code de programme dont la structure est plus correcte et, dans certains cas, d'économiser les ressources du serveur 1C et d'augmenter les performances de la solution d'application.

Dans l'article, nous examinerons les différences fondamentales entre ces modules à la fois du point de vue théorique et à l'aide d'un exemple pratique spécifique.

Théorie

Passons aux bases de la programmation orientée objet (POO) et faisons une analogie avec notre exemple. En POO, les méthodes pour les objets peuvent être divisées en statique et simple. Les méthodes simples ne peuvent être appelées que sur un objet spécifique auquel nous avons accès dans le contexte de code actuel. Les méthodes statiques n'ont pas d'accès direct aux données des objets. Pour accéder à un objet, vous devez d'abord en créer une instance. Il en va de même pour la plateforme 1C:Enterprise 8.x.

Dans le module objet, la plateforme stocke des procédures et des fonctions qui ne peuvent être appelées que lorsque l'on travaille avec un objet spécifique, par exemple avec l'objet de l'élément de répertoire « Nomenclature ». Le module gestionnaire contient des procédures et des fonctions qui peuvent être appliquées à tous les objets d'un type donné, mais avec la création initiale d'une instance de cet objet. Autrement dit, pour modifier un élément de nomenclature à partir de ce module, exécutez d'abord la méthode « GetObject() » pour référencer l'élément, puis travaillez avec lui.

Passons de la théorie à la pratique.

Pratique

Passons à un exemple pratique. Supposons que nous devions résoudre le problème de l'impression d'une liste de produits. L'utilisateur imprime un produit soit directement à partir d'un élément de répertoire, soit à partir du formulaire de liste de produits. Considérons deux façons d'accomplir la tâche.

Procédure d'impression dans le module objet

Dans le module objet répertoire, ajoutez la fonction suivante :

// Passe une référence à un élément de répertoire à la fonction Fonction PrintSelectedProducts(Link) Export TabDoc = New TabularDocument ; Disposition = Répertoires. Marchandises. GetLayout("Mise en page"); Demande = Nouvelle demande ; Demande. Texte = " SELECT | Produits . Présentation AS Produit,| Marchandises . Marquer la suppression,| Marchandises . code de fournisseur |DEPUIS| Annuaire . Produits AS Produits|OÙ | Marchandises . Lien B (&Tableau de produits)" ; Request. SetParameter(" Tableau de produits ", Link); //Sélection par lien

Le code du programme est entièrement généré par le concepteur d'impression. La seule chose à noter est l'affichage par référence à l'élément du répertoire « Produits » dans la requête. La référence est passée en paramètre à la fonction. Suite à l'appel de la fonction "PrintSelectedProducts", une feuille de calcul avec la position terminée du produit sera renvoyée.

Le code du programme permettant d'appeler la méthode objet "PrintSelectedProducts" à l'aide de la commande de formulaire "Imprimer" est présenté dans le listing suivant :

&SurClient Procédure Imprimer(Commande) // Contacter la procédure serveur pour recevoir le tableur généré TabDoc = Serveur d'impression(); // Afficher la feuille de calcul générée TabDoc. Montrer() ; EndProcedure et fonction OnServer PrintServer() // Convertit l'objet formulaire en objet répertoire "Produits" pour appeler une fonction depuis le module objet ObjectItem = FormAttributeValue("Objet" ) ; // Appelez la procédure du module objet, en y passant un lien vers l'élément du répertoire courant. Résultat // retour côté client Renvoie ObjetProduit. PrintSelectedProducts(Object.Link) ; FinFonction

Ainsi, nous avons imprimé l'élément du répertoire courant en travaillant avec son objet. Mais la tâche consistait à imprimer une liste de produits que l'utilisateur devait sélectionner lui-même. Lorsqu'on travaille avec un objet, il n'est pas possible de donner à l'utilisateur une telle opportunité de manière simple. La manière la plus correcte serait d'imprimer à partir de la liste des éléments du répertoire « Produits ».

Procédure d'impression dans le module gestionnaire

Ajoutons la procédure d'export suivante au module de gestion d'annuaire :

// Passe un tableau de liens vers des produits Fonction PrintSelectedProducts(ArrayProducts) Export TabDoc = New TabularDocument ; Disposition = Répertoires. Marchandises. GetLayout("Mise en page"); Demande = Nouvelle demande ; Demande. Texte = " SELECT | Produits . Présentation AS Produit,| Marchandises . Marquer la suppression,| Marchandises . code de fournisseur |DEPUIS| Annuaire . Produits AS Produits|OÙ | Marchandises . Lien B (&Tableau de produits)" ; Request. SetParameter(" Tableau de produits ", Tableau de produits) ; // Définir la sélection par tableau Résultat = Demande. Courir();

La principale différence avec une fonction dans un module objet est le paramètre de fonction. Désormais, un tableau contenant des liens vers des produits à imprimer est passé en paramètre.

Le code du programme du module de commande du formulaire « Imprimer » ressemble à ceci :

& Sur la procédure client Print(Command) TabDoc = PrintServer() ; TabDoc. Montrer() ; EndProcedure et fonction OnServer PrintServer() // Passe un tableau de liens de produits sélectionnés dans la liste des répertoires // dans la fonction du module gestionnaire "PrintSelectedProducts" Répertoires de retour. Marchandises. PrintSelectedItems(Items.List.SelectedRows) ; FinFonction

Dans ce cas, le résultat de l'exécution de la commande en mode 1C:Enterprise sera le suivant :

Si nous utilisons la méthode du module gestionnaire, nous pouvons accéder aux données du répertoire « Produits » sans obtenir d'objet pour chaque lien. Étant donné qu'obtenir un objet signifie obtenir toutes les données de la base de données pour un élément de répertoire et placer les données reçues dans la RAM, la mise en œuvre de la tâche de la deuxième manière aura un effet positif sur les performances. Après tout, dans ce cas, nous utiliserons un minimum de ressources (RAM) de la machine serveur.

Quoi utiliser ?

Comme toujours, tout dépend de la tâche spécifique. Si vous devez imprimer un document, la meilleure option consiste à utiliser le module gestionnaire. Si vous devez remplir un objet, par exemple par un traitement externe de remplissage de parties tabulaires, dans ce cas, il est préférable de placer des procédures et des fonctions dans le module objet, car elles fonctionnent spécifiquement avec l'objet.

Dans la configuration standard de "Trade Management" version 11, le module gestionnaire est utilisé partout pour l'impression des documents. Si vous regardez la configuration « Manufacturing Enterprise Management », le module gestionnaire n'est pratiquement pas utilisé, car la configuration a été écrite dans les anciennes versions de la plate-forme, où il n'y avait pas de prise en charge complète de ce mécanisme.

Configuration avec des exemples de l'article.

Les modules logiciels contiennent du code exécutable en langage 1C, nécessaire pour répondre d'une certaine manière aux actions du système ou de l'utilisateur lorsque les outils de développement visuel ne suffisent pas. Nous pouvons également décrire nos propres méthodes (procédures et fonctions) dans des modules logiciels.

Généralement, un module logiciel se compose de trois sections :

• zone de déclaration des variables;
• zone de description des procédures et des fonctions;
• texte principal du programme.

Exemple de structure de module de programme :

//***************** ZONE DE DÉCLARATION VARIABLE **********************

Exportation du nom de famille Perem ; / / ceci est une variable globale
Changer le nom, le patronyme ; // ceci est une variable de module
Nom complet de Perem ; // ceci est également une variable de module et est accessible

//depuis n'importe quelle procédure et fonction de notre module

//*************** ZONE DESCRIPTION DES PROCÉDURES ET FONCTIONS ****************

Procédure Procédure1 ()
Total variable ; / /Result est une variable locale (variable de procédure)

Total = Nom + " "+ Prénom + " "+ Deuxième prénom ;

Fin de la procédure

Fonction Fonction1()

// opérateurs de fonction

Retour (Nom + " "+ Prénom);

FinFonction

//********************* TEXTE PRINCIPAL DU PROGRAMME **********************

Nom = « Ivanov » ;
Nom = « Ivan » ;
Patronymique = « Ivanovitch » ;

//******************************************************************************

Dans un module logiciel particulier, l'une des zones peut manquer.
Zone de déclaration des variables placé du début du texte du module à la première instruction de procédure ou de fonction ou à toute instruction exécutable. Cette section ne peut contenir que des instructions de déclaration de variable Variable.

Zone de description des procédures et des fonctions placé de la première instruction de procédure ou de fonction à toute instruction exécutable en dehors du corps de la description de procédure ou de fonction.

Zone de texte du programme principal est placé depuis la première instruction exécutable en dehors du corps des procédures ou des fonctions jusqu'à la fin du module. Cette section ne peut contenir que des instructions exécutables. La zone de texte principale du programme est exécutée au moment de l'initialisation du module. Habituellement, dans une section du programme principal, il est logique de placer des opérateurs pour initialiser des variables avec des valeurs spécifiques qui doivent être attribuées avant le premier appel aux procédures ou aux fonctions du module.

Les modules logiciels sont situés aux endroits de la configuration qui peuvent nécessiter une description d'algorithmes de fonctionnement spécifiques. Ces algorithmes doivent être formalisés sous forme de procédures ou de fonctions qui seront appelées par le système lui-même dans des situations prédéterminées (par exemple, lors de l'ouverture d'un formulaire répertoire, lors de l'appui sur un bouton dans une boîte de dialogue, lors de la modification d'un objet, etc.) .

Chaque module logiciel individuel est perçu par le système comme un tout, de sorte que toutes les procédures et fonctions du module logiciel sont exécutées dans un contexte unique.

Le contexte d'exécution du module est divisé en client et serveur. De plus, certains modules logiciels peuvent être compilés aussi bien côté client que côté serveur.

Module d'application (géré ou régulier)

Le module applicatif décrit les procédures (gestionnaires) des événements initialisés au début et à la fin du système. Par exemple, lorsque l'application démarre, vous pouvez mettre à jour certaines données de configuration et lorsque vous quittez l'application, vous pouvez demander s'il vaut la peine de quitter le programme. De plus, ce module intercepte les événements provenant d'équipements externes, par exemple commerciaux ou fiscaux. Il convient de noter que le module applicatif n'est exécuté que lorsque l'application est lancée de manière interactive, c'est-à-dire lorsque la fenêtre du programme est lancée. Cela ne se produit pas si l'application est lancée en mode connexion com.
Dans la plateforme 1C 8, il existe deux modules d'application différents. Il s’agit du module Application régulière et du module Application gérée. Ils sont déclenchés au lancement de différents clients. Ainsi, le module Managed Application se déclenche lorsque le client web, le client léger et le client lourd sont lancés en mode application managée. Et le module d'application standard est déclenché lorsque le client lourd est lancé en mode application normal. Le paramètre du mode de lancement de l'application est précisé dans la propriété de configuration "Mode de lancement de base".

Un module d'application peut contenir les 3 sections - déclarations de variables, descriptions de procédures et de fonctions, ainsi que le texte principal du programme. Le module applicatif est compilé côté client, ce qui limite grandement notre utilisation de nombreux types de données. Vous pouvez étendre le contexte du module d'application à l'aide de méthodes de modules communs dont la propriété « Appel au serveur » est définie. Toutes les variables et méthodes du module d'application marquées comme exportées seront disponibles dans n'importe quel module de configuration exécuté côté client. Cependant, aussi tentant que cela puisse être, vous ne devez pas placer ici un grand nombre de procédures et de fonctions. Plus il y a de code dans un module donné, plus le temps de compilation est long, et par conséquent le temps de lancement de l'application.

Comme indiqué ci-dessus, le module d'application gère les événements de démarrage et de fin d'application. Pour gérer chacun de ces événements dans le module d'application, il existe une paire de gestionnaires Avant... et Quand... Les différences entre eux sont les suivantes : lors de l'exécution de code dans le gestionnaire Avant..., l'action n'a pas encore été exécutée. a eu lieu et nous pouvons refuser de l'exécuter. C'est à cela que sert l'option Rejeter. Dans les gestionnaires On.., l'action a déjà eu lieu, et on ne peut pas refuser de lancer l'application ou d'en sortir.

Module de connexion externe

• peut contenir les 3 zones
• situé dans la section racine de la configuration

L'objectif du module est similaire à celui du module d'application. Il traite les événements de début et de fin de l'application. Le module de connexion externe se déclenche au lancement de l'application en mode connexion com. Le processus de jointure externe lui-même n'est pas un processus interactif. Dans ce mode, le travail programmatique avec la base d'informations se produit et la fenêtre de l'application ne s'ouvre pas, ce qui impose certaines restrictions sur l'utilisation de méthodes destinées au travail interactif. Dans ce mode, les appels aux formulaires de dialogue, les avertissements et les messages à l'utilisateur, etc. ne peuvent pas être utilisés. Ils ne seront tout simplement pas exécutés.

Comme dans le module d'application, les trois zones sont disponibles ici : déclarations de variables, descriptions de procédures et de fonctions, ainsi que le texte principal du programme. La principale différence avec le module d'application est qu'en mode de connexion com, tout le travail avec l'infobase se produit côté serveur, de sorte que le module de connexion externe est compilé côté serveur. Par conséquent, les variables d'exportation et les méthodes des modules clients courants n'y sont pas disponibles.

Module de séance

• fonctionne côté serveur
• situé dans la section racine de la configuration

Il s'agit d'un module hautement spécialisé conçu exclusivement pour initialiser les paramètres de session. Pourquoi avez-vous dû créer votre propre module pour cela ? Son utilisation est due au fait que l'application elle-même peut être lancée dans différents modes (entraînant l'exécution soit d'un module d'application géré, soit d'un module d'application standard, soit d'un module de connexion externe), et l'initialisation des paramètres de session doit être effectuée indépendamment. du mode de démarrage. Afin de ne pas écrire le même code de programme dans ces trois modules, nous avions besoin d'un module supplémentaire qui s'exécute quel que soit le mode de lancement de l'application.

Dans le module de session, il existe un seul événement « SettingSessionParameters », qui est exécuté en premier, avant même l'événement du module d'application BeforeSystemStartOperation. La section de déclaration de variable et la section du programme principal n'y sont pas disponibles. Vous ne pouvez pas non plus déclarer de méthodes d'exportation. Le module est compilé côté serveur.

Modules communs

• peut contenir une zone décrivant les procédures et les fonctions
• exécuté côté serveur ou client (selon les paramètres du module)
• se trouve dans l'arborescence des objets de configuration « Général » - « Modules généraux »

Les modules communs sont destinés à décrire certains algorithmes courants qui seront appelés depuis d'autres modules de configuration. Le module général ne contient pas de zones de déclaration de variables ni le texte principal du programme. Vous pouvez y déclarer des méthodes d'export dont la disponibilité sera déterminée par les paramètres du module (de quel côté il est exécuté : côté serveur ou côté client). En raison du fait que la section de description des variables n'est pas disponible, les variables globales ne peuvent pas être définies dans les modules communs. Vous pouvez utiliser un module d'application pour cela.

Le comportement d'un module commun dépend des paramètres définis (globaux ou non, divers drapeaux de compilation, disponibilité d'un appel serveur, etc.). Voici quelques conseils pour mettre en place des modules communs :

Il est de bonne pratique de ne pas utiliser le drapeau mondial partout. Cela réduira le temps de démarrage de l'application, et améliorera également la lisibilité du code (bien sûr, si le module commun a un nom tout à fait significatif) ;
- Il n'est pas conseillé d'utiliser plus d'un indicateur de compilation. Il n'y a pas tellement de méthodes qui doivent être exécutées dans différents contextes, et si de telles méthodes sont toujours nécessaires, alors un module commun distinct peut leur être alloué ;
- le flag « Appeler le serveur » n'a de sens que si le module est compilé « Sur le serveur ». Par conséquent, tous les autres indicateurs de compilation doivent être supprimés pour éviter divers problèmes ;
- si les méthodes du module impliquent un traitement massif de données, une lecture et une écriture dans la base de données, alors pour augmenter la vitesse de travail, il est préférable de désactiver le contrôle des droits d'accès en définissant l'indicateur « Privilégié ». Ce mode n'est disponible que pour les modules partagés compilés sur le serveur.

Module de formulaire

• peut contenir les 3 zones
• exécuté côté serveur et côté client

Le module de formulaire est conçu pour traiter les actions des utilisateurs avec ce formulaire (traitement d'un événement de clic sur un bouton, modification des attributs du formulaire, etc.). Il existe également des événements associés directement au formulaire lui-même (par exemple, son ouverture ou sa fermeture). Les modules de formulaires gérés et réguliers diffèrent, tout d'abord, en ce que le module d'un formulaire géré est clairement divisé en contexte. Chaque procédure ou fonction doit avoir une directive de compilation. Si la directive de compilation n'est pas spécifiée, alors cette procédure ou fonction est exécutée côté serveur. Dans sa forme normale, tout le code est exécuté côté client.

La structure d'un formulaire géré contient une section pour les déclarations de variables, les descriptions de procédures et de fonctions, ainsi que le texte principal du programme (exécuté au moment de l'initialisation du formulaire). Nous pouvons accéder aux événements du formulaire standard à travers la liste des procédures et fonctions attendues du formulaire (Ctrl+Alt+P), ou via la palette de propriétés du formulaire lui-même.

Si un formulaire est doté d'un attribut principal, les propriétés et méthodes de l'objet d'application utilisé comme attribut principal deviennent disponibles dans le module de formulaire.

Module objet

• peut contenir les 3 zones
• fonctionne côté serveur

Ce module est disponible pour la plupart des objets de configuration et est généralement destiné au traitement des événements directement liés à l'objet. Par exemple, les événements d'enregistrement et de suppression d'objets, la vérification de l'achèvement des détails de l'objet, la publication d'un document, etc.

Certains événements de module objet dupliquent les événements du module de formulaire. Par exemple, les événements associés à un enregistrement. Cependant, il faut comprendre que les événements du module formulaire seront exécutés exclusivement dans le formulaire spécifique de l'objet, c'est-à-dire lors de l'ouverture du formulaire spécifique. Et les événements du module objet seront appelés dans tous les cas, même au moment du travail de programmation avec l'objet. Par conséquent, si vous avez besoin de méthodes associées à un objet sans être liées à une forme spécifique de l'objet, il est préférable d'utiliser le module objet pour cela.

Module gestionnaire d'objets

• peut contenir les 3 zones
• fonctionne côté serveur

Le module gestionnaire d'objets n'est apparu qu'à partir de la version 1C 8.2. Le module gestionnaire existe pour tous les objets applicatifs et est conçu pour gérer cet objet en tant qu'objet de configuration. Le module gestionnaire vous permet d'étendre les fonctionnalités d'un objet en introduisant (en écrivant) des procédures et des fonctions qui ne se rapportent pas à une instance spécifique d'un objet de base de données, mais à l'objet de configuration lui-même. Le module gestionnaire d'objets permet de placer des procédures et fonctions générales pour un objet donné et d'y accéder de l'extérieur, par exemple depuis le traitement (bien sûr, si cette procédure ou fonction possède le mot-clé Export). Quelle nouveauté cela nous apporte-t-il ? En général, rien d'autre que d'organiser les procédures par objets et de les stocker dans des endroits séparés - Modules Object Manager. Nous pouvons tout aussi bien placer ces procédures et fonctions dans des modules généraux, mais 1C recommande de placer les procédures générales et les fonctions des objets dans le module Gestionnaire d'objets. Exemples d'utilisation des procédures et fonctions du module Gestionnaires d'objets : premier remplissage individuel d'un répertoire ou d'un document sous certaines conditions, vérification de la complétion des détails d'un répertoire ou d'un document sous certaines conditions, etc.

Module de commande

• peut contenir une section décrivant les procédures et les fonctions
• exécuté côté client

Les commandes sont des objets subordonnés aux objets d'application ou à la configuration dans son ensemble. Chaque commande possède un module de commande dans lequel une procédure CommandProcess() prédéfinie peut être décrite pour exécuter cette commande.