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 plate-forme 7.7, où le code pouvait être situé à la fois dans les propriétés des éléments de formulaire et dans les cellules des tableaux de disposition, dans la plate-forme 8.x, toute ligne de code doit être localisée dans certains modules. 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 pour presque tous les modules de plate-forme, à quelques exceptions près. Certains modules n'ont pas de section de déclaration de variable ni de section de programme principal. Par exemple, le module de session et tout module général.

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

Module d'application

Le module est conçu pour capter les instants de lancement de l'application (chargement de la configuration) et de son achèvement. Et dans les événements correspondants, vous pouvez organiser les procédures de vérification. Par exemple, au début de l'application, mettez à jour toutes les données de référence de configuration, à la fin du travail, demandez si cela vaut la peine de le laisser, 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, tels que les équipements commerciaux ou fiscaux. Il est à noter que le module applicatif n'intercepte les événements décrits que dans le cas d'un lancement interactif. 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 connexions com.

Il existe deux modules d'application différents dans la plate-forme 8.2. Il s'agit du module Application commune et du module Application gérée. Ils sont déclenchés lorsque différents clients sont démarrés. C'est ainsi que le module d'application gérée se déclenche 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 d'application normal.

Toutes les sections peuvent être placées dans le module d'application - descriptions des variables, des procédures et des fonctions, ainsi que des descriptions du programme principal. Le module d'application est compilé côté client, ce qui limite considérablement la disponibilité de nombreux types de données. Vous pouvez étendre le contexte d'un module d'application avec les méthodes des modules partagés dont la propriété Call Server est définie. Toutes les variables et méthodes marquées comme export seront disponibles dans n'importe quel module de configuration côté client. Cependant, aussi tentant soit-il, il ne devrait pas être publié ici un grand nombre de méthodes. Plus il contient de code, plus le temps de compilation est long et, par conséquent, le temps de démarrage 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ébut et de fin de l'application. Pour gérer chacun de ces événements dans le module d'application, il existe deux gestionnaires Before ... et When ... La différence entre eux est que lorsque le code du gestionnaire Before ... est exécuté, l'action n'a pas encore eu lieu et nous pouvons refuser de l'exécuter. C'est à cela que sert l'option Refus. Dans les gestionnaires On, l'action a déjà eu lieu, et on ne peut pas refuser de lancer l'application ou de la quitter.

Module de connexion externe

L'objectif du module est similaire à l'objectif du module d'application. Il gère 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 com-connexion. Le processus de jointure externe lui-même n'est pas un processus interactif. Dans ce mode, le programme fonctionne avec base d'informations et la fenêtre de l'application ne s'ouvre pas, ce qui impose certaines restrictions à l'utilisation des méthodes destinées au travail interactif. Dans ce mode, vous ne pouvez pas utiliser les appels de formulaire de dialogue, les messages d'avertissement, etc. Ils ne fonctionneront tout simplement pas.

Comme dans le module d'application, des sections pour décrire les variables, les 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 com-connexion, tout le travail avec l'infobase se produit 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 communs n'y sont pas disponibles.

module de session

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

Il existe un seul événement "SetSessionParameters" dans le module de session, qui est déclenché en premier, avant même l'événement BeforeSystemStart du module d'application. Il n'a pas de section de déclaration de variable ni de section de programme principal. Et aussi il est impossible de déclarer les méthodes d'exportation. Le module est compilé côté serveur.

Evitez la tentation que ce module soit exécuté à chaque lancement de l'application, et placez-y du 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 lorsque nous accédons à des paramètres non initialisés. Et bien qu'il soit possible d'attraper le moment du premier lancement de cet événement (RequiredParameters a le type Undefined), cependant, il convient de noter 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, nous ne pouvons toujours pas être sûrs à cent pour cent que le système sera lancé. Soudainement, le module d'application échouera et nous essayons d'effectuer une action avec la base de données.

Modules généraux

Les modules sont destinés à décrire certains algorithmes communs qui seront appelés à partir d'autres modules de configuration. Le module général ne contient pas de section de déclaration de variable et 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 drapeaux de compilation. Du fait que la section de déclaration des variables n'est pas disponible, il n'est pas possible de définir des variables globales dans les modules partagés. Pour ce faire, vous devez utiliser les fonctions des 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 commun 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 où elles ont été dernier accès.
Le comportement du module partagé dépend des paramètres définis (globaux ou non, divers drapeaux de compilation, si un appel serveur est disponible, 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 lorsque les indicateurs de propriété sont définis de manière déraisonnable. Ceci est un sujet pour un article séparé. Arrêtons-nous sur quelques points à suivre lors de la définition des drapeaux :

• C'est une bonne règle de base de ne pas utiliser le drapeau "Global" partout. Cela réduira le temps de démarrage de l'application et améliorera la lisibilité du code (bien sûr, si le module commun a un nom complètement 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 néanmoins nécessaires, un module commun séparé peut leur être attribué.
• Le drapeau "Call Server" 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 afin d'éviter divers problèmes.
• Si les méthodes du module sont utilisées pour le traitement de données en masse, la lecture et l'é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 d'accès en définissant le drapeau "Privilégié". Ce mode n'est disponible que pour les modules partagés compilés sur le serveur.

Module de formulaire

Il est destiné à traiter les actions de l'utilisateur, c'est-à-dire divers événements liés à la saisie des données et au traitement de l'exactitude de leur saisie. Le module de formulaire régulier est entièrement compilé sur le client. Le module formulaire géré clairement délimité par le contexte d'exécution, de sorte que 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. Dans le module de formulaire, des sections pour décrire les variables et les méthodes sont disponibles, ainsi qu'une section pour le programme principal.

Module objet

Ce module est typique de nombreux objets de configuration et est destiné, en général, au traitement des événements d'objets. Par exemple, les événements d'écriture et de suppression d'objets, l'événement de publication de documents, etc.

Certains événements de module d'objet dupliquent des événements de module de formulaire. Par exemple, les événements liés à l'enregistrement. Cependant, il faut comprendre que les événements du module de formulaire ne seront exécutés que sur un objet de formulaire particulier. 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 pour le moment programme de travail avec un objet. Par conséquent, s'il est nécessaire d'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. Dans celui-ci, vous pouvez définir des variables et des méthodes d'exportation qui seront disponibles dans d'autres modules de configuration. Avec l'aide de 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 au moment de la saisie par ligne et d'étendre les fonctionnalités du gestionnaire. Le module est compilé côté serveur. Il est possible de définir des propriétés et des méthodes d'exportation. L'appel des méthodes d'exportation du gestionnaire ne nécessite pas la création de l'objet lui-même.

À tout ce qui précède, vous pouvez ajouter une image de certains modules de configuration et des moyens d'appeler mutuellement des méthodes en mode application gérée. La flèche indique le sens dans lequel vous pouvez aller pour appeler la méthode correspondante. Comme on peut le voir sur 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 commun de serveur ; M. F. Client - Procédures client du module formulaire ; M. F. Serveur - Procédures serveur du module formulaire.

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 visuels ne suffisent pas. Dans les modules du programme, nous pouvons également décrire nos propres méthodes (procédures et fonctions).

En règle générale, un module logiciel se compose de trois sections :

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

Un exemple de structure d'un module de programme :

//******************** ZONE DE DECLARATION VARIABLE *************************

Exportation du nom de famille Rem ; / /c'est une variable globale
Nom de variable, Patronyme ; // ceci est une variable de module
Changer de nom; // c'est aussi une variable de module et on peut y accéder

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

//*************** PROCÉDURE ET ZONE DE DESCRIPTION DES FONCTIONS ****************

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

Total = Nom + "" + Prénom + " "+ Patronyme ;

FinProcédure

Fonction Fonction1 ()

// instructions de fonction

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

EndFunctions

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

Nom = "Ivanov" ;
Nom = "Ivan" ;
Deuxième prénom = "Ivanovich" ;

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

Dans un module de programme particulier, n'importe lequel des domaines peut manquer.
Périmètre de déclaration des variables est placé du début du texte du module jusqu'à la première instruction de l'instruction Procedure ou Function ou de toute instruction exécutable. Cette section ne peut contenir que des instructions de déclaration de variable.

Zone de description des procédures et des fonctions est placé de la première instruction d'une instruction Procedure ou Function à toute instruction exécutable en dehors du corps d'une déclaration de procédure ou de fonction.

Zone de texte du programme principal est placé de 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 du texte principal du programme est exécutée au moment de l'initialisation du module. Habituellement, dans la section principale du programme, il est logique de placer des instructions pour initialiser des variables avec des valeurs spécifiques qui doivent être affectées avant le premier appel aux procédures ou fonctions du module.

Les modules de programme sont situés aux endroits de la configuration qui peuvent nécessiter la description d'algorithmes de fonctionnement spécifiques. Ces algorithmes doivent être conçus comme des procédures ou des 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 de référence, lors d'un clic sur un bouton dans une boîte de dialogue, lors d'un changement d'objet, etc.).

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

Le contexte d'exécution des modules est divisé en contextes 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 qui sont initialisés au début et à la fin du système. Par exemple, lorsque vous démarrez une application, vous pouvez mettre à jour certaines données de configuration, et lorsque vous quittez, vous pouvez demander si vous devez quitter le programme. De plus, ce module intercepte les événements provenant d'équipements externes, tels que des équipements commerciaux ou fiscaux. Il est à noter que le module applicatif n'est exécuté que dans le cas d'un lancement interactif de l'application, c'est-à-dire lors du lancement de la fenêtre du programme. Cela ne se produit pas si l'application est lancée en mode com-connexion.
Il existe deux modules d'application différents dans la plate-forme 1C 8. Il s'agit du module Application commune et du module Application gérée. Ils sont déclenchés lorsque différents clients sont démarrés. Par exemple, 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 d'application normal. Le paramètre du mode de lancement de l'application est défini dans la propriété de configuration "Mode de lancement principal".

Le 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 d'application est compilé côté client, ce qui nous empêche fortement d'utiliser de nombreux types de données. Vous pouvez étendre le contexte d'un module d'application avec les méthodes des modules partagés dont la propriété Call Server est définie. Toutes les variables et méthodes du module de programme d'application marquées comme export seront disponibles dans n'importe quel module de configuration 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 démarrage de l'application.

Comme indiqué ci-dessus, le module d'application gère les événements de début et de fin de l'application. Pour gérer chacun de ces événements dans le module d'application, il existe deux gestionnaires Before ... et When ... Les différences entre eux sont les suivantes : lorsque le code du gestionnaire Before ... est exécuté, l'action a pas encore eu lieu et nous pouvons refuser de l'exécuter. C'est à cela que sert l'option Refus. Dans les gestionnaires On, l'action a déjà eu lieu, et on ne peut pas refuser de lancer l'application ou de la quitter.

Module de connexion externe

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

L'objectif du module est similaire à l'objectif du module d'application. Il gère 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 com-connexion. Le processus de jointure externe lui-même n'est pas un processus interactif. Dans ce mode, le travail par programmation avec l'infobase se produit et la fenêtre de l'application ne s'ouvre pas, ce qui impose certaines restrictions à l'utilisation de méthodes destinées au travail interactif. Dans ce mode, vous ne pouvez pas utiliser les appels aux formulaires de dialogue, les avertissements et les messages à l'utilisateur, etc. Ils ne courront tout simplement pas.

Comme dans le module applicatif, les trois zones sont disponibles ici : les déclarations de variables, les descriptions des procédures et des fonctions, ainsi que le texte principal du programme. La principale différence avec le module d'application est qu'en mode com-connexion, 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 communs n'y sont pas disponibles.

module de session

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

Il s'agit d'un module hautement spécialisé conçu uniquement pour initialiser les paramètres de session. Pourquoi avez-vous eu besoin de créer votre propre module pour cela ? Son utilisation est due au fait que l'application elle-même peut être lancée en divers modes(entraînant l'exécution d'un module d'application géré, d'un module d'application normal ou d'un module de connexion externe), et les paramètres de session doivent être initialisés quel que soit le 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.

Il existe un seul événement "SetSessionParameters" dans le module de session, qui est déclenché en premier, avant même l'événement PreSystemBegin du module d'application. Il n'a pas de section de déclaration de variable ni de section de programme principal. Et aussi il est impossible de déclarer les méthodes d'exportation. Le module est compilé côté serveur.

Modules généraux

• peut contenir une zone pour décrire les procédures et les fonctions
• exécuté côté serveur ou côté client (dépend des paramètres du module)
• situé dans la branche de l'arborescence des objets de configuration "Général" - "Modules généraux"

Les modules communs sont destinés à décrire certains algorithmes communs qui seront appelés à partir d'autres modules de configuration. Le module général ne contient pas les zones de déclaration des variables et le corps 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). Du fait que la section de déclaration des variables n'est pas disponible, il n'est pas possible de définir des variables globales dans les modules partagés. Vous pouvez utiliser le module d'application pour cela.

Le comportement du module partagé dépend des paramètres définis (globaux ou non, divers drapeaux de compilation, si un appel serveur est disponible, etc.). Voici quelques conseils pour configurer des modules partagés :

Il est recommandé de ne pas utiliser le drapeau "Global" partout. Cela réduira le temps de démarrage de l'application et améliorera la lisibilité du code (bien sûr, si le module commun a un nom complètement 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 néanmoins nécessaires, alors un module commun séparé peut leur être attribué ;
- le drapeau "Appel 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 afin d'éviter divers problèmes ;
- si dans les méthodes du module il y a un traitement de masse des données, lecture et é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 d'accès en définissant le drapeau "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
• effectuée côté serveur et côté client

Le module de formulaire est conçu pour gérer les actions de l'utilisateur avec ce formulaire (gestion de l'événement de clic sur le bouton, modification de l'attribut du formulaire, etc.). Il existe également des événements liés directement au formulaire lui-même (par exemple, son ouverture ou sa fermeture). Les modules de formulaire géré et les modules de formulaire standard diffèrent principalement en ce qu'un module de formulaire géré est clairement séparé dans un 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 la forme habituelle, tout le code est exécuté côté client.

La structure du formulaire géré contient une section de déclaration de variable, des descriptions de procédures et de fonctions, et le corps du programme (exécuté lors de l'initialisation du formulaire). Nous pouvons accéder aux événements de formulaire standard via 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 l'attribut principal est affecté au formulaire, les propriétés et les 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
• effectué côté serveur

Ce module est disponible pour la plupart des objets de configuration et est destiné, en général, 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 que les détails d'un objet sont renseignés, la publication d'un document, etc.

Certains événements de module d'objet dupliquent des événements de module de formulaire. Par exemple, les événements liés à l'enregistrement. Cependant, il faut comprendre que les événements du module de formulaire ne seront exécutés que sur le formulaire spécifique de l'objet, c'est-à-dire lorsque le formulaire spécifique est ouvert. Et les événements du module objet seront appelés dans tous les cas, même au moment du travail du programme 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
• effectué 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 comme un objet de configuration. Le module gestionnaire vous permet d'étendre la fonctionnalité d'un objet en introduisant (en écrivant) des procédures et des fonctions qui ne s'appliquent pas à une instance spécifique de l'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 des fonctions communes pour un objet donné et d'y accéder depuis l'extérieur, par exemple depuis le traitement (bien sûr, si cette procédure ou fonction est avec le mot-clé Export). Qu'est-ce que cela nous apporte de nouveau ? 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 de gestion d'objets. On peut tout aussi bien placer ces procédures et fonctions dans des modules communs, mais 1C conseille de placer les procédures et fonctions communes des objets dans le module Object Manager. Exemples d'utilisation des procédures et fonctions du Module Gestionnaires d'Objets : premier remplissage des fiches individuelles d'un répertoire ou d'un document sous certaines conditions, contrôle du remplissage des fiches 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 a un module de commande dans lequel vous pouvez décrire une procédure CommandProcess() prédéfinie pour exécuter cette commande.

Tout programme consiste en un code de programme, c'est-à-dire en fait à partir 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 qu'il doit être 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 l'extension qu'ils contiennent n'est pas .txt, mais .cpp ou .php.

Où est écrit le programme 1C ?

Qu'est-ce que le Module 1C ?

Bien sûr, le code 1C peut é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 formulaire et d'autres éléments, mais également un code de 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à considéré dans les leçons précédentes. Chaque objet 1C contient des objets imbriqués, par exemple, un répertoire a plusieurs formulaires.

Chaque objet 1C, y compris certains imbriqués, a son propre module - un certain fichier texte, qui contient le code du programme.

Il existe également des modules indépendants de l'objet dans lesquels un code de programme indépendant d'un objet particulier peut être écrit.

Ainsi, en 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 précédemment, l'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 DirectoryObject.Write() – écrit un élément du 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 plate-forme 1C) et écrites par un programmeur dans le langage 1C. Avec l'aide de ce dernier, vous pouvez étendre les fonctionnalités des objets 1C à votre guise.

Événements. Les événements se trouvent 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 le 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 écrit l'objet 1C dans la base de données. L'événement système "Enregistrer l'objet" s'est produit. Il est possible de configurer la réaction qui se produira sur les événements causés non pas par l'utilisateur (qui a appuyé sur le 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

Dans de nombreuses langues, il existe un "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.

Il existe plusieurs points d'entrée de ce type dans 1C - pour chaque type de client. C'est-à-dire qu'au démarrage d'un client lourd, le point d'entrée est un, au démarrage d'un client léger, c'en est un autre. Cela vous permet de programmer des fonctions qui sont différentes dans différents types clients.

Le point d'entrée dans le module correspondant est respectivement les gestionnaires d'événements système BeforeSystemStart() et AtSystemStart() (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 ensuite tout en dépend. Il clique sur le bouton - le gestionnaire pour appuyer sur ce bouton est exécuté (qui, à son tour, peut également démarrer quelque chose automatiquement).

Travailler avec des modules 1C

Produit 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 novices ne comprennent pas la différence dans le but 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 côté théorique et sur 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 sur les objets peuvent être divisées en statique (statique) et simple. Méthodes simples ne peut être appelé 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 d'objet. 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 plate-forme 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éférence "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. C'est-à-dire que pour modifier un élément de la nomenclature de ce module, dans un premier temps, pour faire référence à l'élément, exécutez la méthode "GetObject ()", puis travaillez avec elle à l'avenir.

Passons de la théorie à la pratique.

Pratique

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

Procédure d'impression dans le module objet

Dans le module d'objet d'annuaire, ajoutez fonction suivante:

// Passe une référence à l'élément répertoire à la fonction Fonction PrintSelectedItems(Link) Export TabDoc = New TabDoc ; Disposition = Répertoires. Marchandises. GetLayout(" Disposition " ); Demande = Nouvelle demande ; Demande. Texte = " SÉLECTIONNER | Éléments . Présentation AS Marchandises,| Marchandises . Marquer supprimer,| Marchandises . code de fournisseur |DEPUIS| Annuaire . Produits AS Produits| OÙ | Marchandises . Lien B(& ItemsArray)" ; Request. SetParameter(" Tableau de marchandises " , Lien) ; // Définir la sélection par référence

Le code du programme est entièrement généré par le concepteur d'impression. La seule chose à noter est qu'il est affiché par référence à l'élément de répertoire "Produits" dans la requête. La référence est passée en paramètre à la fonction. À la suite de l'appel de la fonction "PrintSelectedItems" sera renvoyé feuille de calcul avec un élément rempli.

Le code programme d'appel de la méthode de l'objet "PrintSelectedProducts" sur la commande du formulaire "Print" est présenté dans le listing suivant :

& OnClient Procedure Print(commande) // Appel de la procédure serveur pour obtenir le document tableur généré TabDoc = PrintServer() ; // Affiche le document de feuille de calcul généré TabDoc. Montrer() ; EndProcedure & OnServer Fonction PrintServer() // Convertit l'objet formulaire en objet du répertoire "Produits" pour appeler la fonction depuis le module objet ItemObject = FormAttributeToValue(" Object " ) ; // Appel de la procédure du module objet en y passant une référence à l'élément courant du dictionnaire. Résultat // retour côté client Renvoie ObjectItem. PrintSelectedItems(Object.Reference) ; EndFunctions

Ainsi, nous avons imprimé l'élément courant du répertoire, en travaillant avec son objet. Mais dans la tâche, il était dit d'imprimer une liste de produits que l'utilisateur lui-même devait choisir. Lorsque vous travaillez avec un objet, il n'est pas possible de donner à l'utilisateur une telle opportunité de manière simple. Il serait plus correct d'imprimer à partir de la liste des éléments du répertoire "Biens".

Procédure d'impression dans le module gestionnaire

Ajoutez la procédure d'exportation suivante au module du gestionnaire d'annuaire :

// Passage d'un tableau de liens vers des produits Fonction PrintSelectedItems(ItemsArray) Export TabDoc = Nouveau SpreadsheetDocument ; Disposition = Répertoires. Marchandises. GetLayout(" Disposition " ); Demande = Nouvelle demande ; Demande. Texte = " SÉLECTIONNER | Éléments . Présentation AS Marchandises,| Marchandises . Marquer supprimer,| Marchandises . code de fournisseur |DEPUIS| Annuaire . Produits AS Produits| OÙ | Marchandises . Lien B(& ItemsArray)" Request.SetParameter(" Tableau d'éléments " , Tableau d'éléments) ; // Définir le filtre par tableau Résultat = Demande. Exécuter () ; AreaTitle = Mise en page. GetRegion(" Titre " ) ; AreaFooter = Mise en page. GetRegion(" Sous-sol " ) ; Zone TableHeader = Mise en page. GetArea("En-tête du tableau" ) ; AreaFooterTables = Mise en page. GetRegion("TableFooter" ) ; AreaDetailRecords = Mise en page. GetRegion(" Détails " ) ; TabDoc. Clair() ; TabDoc. Sortie(EntêteZone) ; TabDoc. Sortie(RegionTableHeader) ; TabDoc. StartAutoGroupRows() ; SampleDetailRecords = Résultat. Choisir() ; Lors de l'échantillonnage des enregistrements détaillés. Next() LoopDetailRecordsArea. Options. Remplir(SelectionDetailRecords) ; TabDoc. Output(RegionDetailRecords, SelectionDetailRecords. Level() ) ; FinCycle ; TabDoc. EndAutoGroupRows() ; TabDoc. Sortie(RegionFooterTables) ; TabDoc. Sortie(Pied de zone) ; Retour TabDoc ; EndFunctions

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 programme du module de commande du formulaire "Imprimer" est le suivant :

& Sur la procédure client Print(Command) TabDoc = PrintServer() ; TabDoc. Montrer() ; EndProcedure & OnServer Fonction PrintServer() // Passage d'un tableau de liens de produits sélectionnés dans la liste de recherche // dans la fonction du module gestionnaire "PrintSelectedItems" Manuels de retour. Marchandises. PrintSelectedItems(Items. List. Selected Lines) ; EndFunctions

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

Dans le cas de l'utilisation de la méthode du module gestionnaire, nous pouvons accéder aux données du catalogue "Produits" sans obtenir un objet pour chaque lien. Étant donné que l'obtention d'un objet signifie obtenir toutes les données de la base de données par l'élément du 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 affectera positivement les performances. En effet, dans ce cas, on utilisera un minimum de ressources ( mémoire vive) de la machine serveur.

Quoi utiliser ?

Comme toujours, tout dépend de la tâche spécifique. Si vous souhaitez imprimer un document, plus Meilleure option- utiliser le module gestionnaire. Si vous devez remplir un objet, par exemple, traitement externe remplissage parties tabulaires, dans ce cas, il est préférable de placer les procédures et les fonctions dans le module objet, car leur travail implique exactement l'objet.

Dans la configuration type "Trade Management" version 11, le module gestionnaire d'impression de documents est utilisé partout. Si vous regardez la configuration "Production Enterprise Management", le module de gestion 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.

Imprimer (Ctrl+P)

Objets situés dans la branche de l'arbre de configuration Les modules communs sont destinés à contenir les textes des fonctions et des procédures pouvant être appelées depuis n'importe quel autre module de configuration.
ATTENTION! Un module générique ne peut contenir que des définitions de procédure et de fonction.
Procédures et fonctions d'un module commun dont les en-têtes indiquent mot-clé Les exportations sont l'une des composantes du contexte mondial. Vous pouvez en savoir plus sur l'écriture de procédures dans un module commun dans les sections "Format des textes sources des modules de programme" et "Opérateurs" de l'aide du langage 1C:Enterprise.
Pour éditer un module commun, dans la palette des propriétés d'un objet de type Modules communs de la fenêtre Configuration, dans la propriété Module, cliquez sur le lien Ouvrir. Le texte du module général sera publié pour être édité dans l'éditeur de texte 1C:Enterprise en mode d'édition de texte du module de programme.
Le module commun, faisant partie de la configuration, est enregistré uniquement en tant que partie de la configuration.
La propriété Global détermine si les méthodes exportées d'un module partagé font partie du contexte global.
Si la propriété Global est définie sur True, les méthodes exportées du module partagé sont disponibles en tant que méthodes du contexte global.
Si la propriété Global est définie sur False, une propriété est créée dans le contexte global avec le nom correspondant au nom du module partagé dans les métadonnées. Cette propriété est en lecture seule. La valeur de cette propriété est un objet GenericModule. A travers cet objet, les méthodes exportées de ce module commun sont disponibles. Ainsi, l'accès aux méthodes des modules partagés non globaux ressemble à XXXXX.YYYYY, où XXXXX est le nom de la propriété correspondant au contexte du module partagé, et YYYYY est le nom de la méthode exportée du module partagé.
Exemple:

WorkWithTradeEquipment.ConnectBarcodeScanner();

Contexte divers et modules communs

En utilisant les propriétés des modules communs et les instructions du préprocesseur, vous pouvez organiser l'exécution diverses méthodes modules communs dans le bon contexte.
Chaque propriété du module commun est responsable de la capacité de compiler (et d'exécuter) le module commun dans un contexte particulier.
Les propriétés suivantes sont disponibles, qui sont responsables du contexte dans lequel les méthodes du module partagé sont disponibles :
● Client ( application régulière) – les méthodes du module commun seront disponibles pour le client lourd en mode applicatif normal ;
● – des méthodes de module communes seront disponibles pour le client léger, le client Web et également pour le client lourd dans
mode d'application géré ;
● Serveur - les méthodes du module commun seront disponibles sur le serveur ;
● Jointure externe– les méthodes du module commun seront disponibles dans la connexion externe.
Si plusieurs propriétés sont définies en même temps, cela signifie que les méthodes du module partagé seront disponibles dans plusieurs contextes.
Si un module partagé a la propriété Server et toute autre propriété définie, cela signifie que le module partagé sera disponible sur le serveur et dans le client sélectionné en même temps. En même temps, il faut comprendre qu'il s'agira en fait de plusieurs variantes du code compilé (selon le nombre de clients sélectionnés et pour le serveur lui-même).
Dans ce cas, si une méthode située dans un tel module commun est appelée depuis le côté client, alors la copie client du module commun sera utilisée, et si depuis le serveur, la copie serveur sera utilisée. Dans ce cas, en utilisant des directives de préprocesseur (pour plus de détails, voir ici), vous pouvez « protéger » le serveur du code qui ne peut pas être exécuté dessus.
Prenons un exemple. Dans un module partagé (exécutable sur client léger et sur le serveur) il existe une méthode qui a un comportement légèrement différent côté client léger et côté serveur. Voyons comment cela peut être fait :

#Si client léger alors
// Afficher l'avertissement
Afficher l'utilisateur d'alerte("Sur le client");
#Fin si
FinProcédure
Ensuite côté serveur, le code ressemblera à ceci :
Procédure Méthode CommonModule() Exporter
// Divers codes importants vont ici
FinProcédure
Et côté client léger, le code ressemblera à ceci :
Procédure CommonModule Method() Export
// Divers codes importants vont ici
// Afficher l'avertissement
ShowUserAlert("Sur le client");
FinProcédure

Il existe plusieurs façons de transférer le contrôle du client vers le serveur :
● appeler une méthode de module commune du serveur ;
● dans un formulaire ou un module de commande, appeler une méthode précédée de directives de compilation &SurServeur, &SurServeurSansContexte

Cependant, il n'est pas possible d'appeler des méthodes de modules communs client (qui n'ont pas la propriété Server définie) et des méthodes client d'un module de formulaire ou d'un module de commande à partir de procédures serveur. Le contrôle reviendra au client une fois l'appel le plus externe à la méthode serveur terminé.
L'exception concerne les méthodes du module de formulaire et du module de commande, qui sont précédées de directives de compilation &Chez le clientChez le serveur, &Chez le clientChez le serveurSans contexte
Les points suivants doivent également être mentionnés :
● Si un module partagé est disponible pour plusieurs clients, lors de l'écriture du code, tenez compte des restrictions maximales que les clients peuvent imposer ou utilisez les instructions du préprocesseur pour « isoler » le code spécifique au client.
● Les instructions de préprocesseur ont également un sens lorsqu'un module commun a plusieurs contextes d'exécution, comme une connexion externe et un client léger, ou (plus communément) un client et un serveur. Dans ce cas, les instructions du préprocesseur encapsuleront du code interactif qui ne peut pas être utilisé sur le serveur, mais qui est possible sur le client (voir l'exemple ci-dessus).
Pour plus d'informations sur les instructions du préprocesseur et les directives de compilation, consultez la section Exécution des procédures et des fonctions de l'aide 1C:Enterprise Language.
La propriété Server Invocation contrôle si les méthodes exportées du module commun du serveur peuvent être appelées à partir du code client.
Si la propriété est définie, les méthodes exportées du module partagé côté serveur peuvent être appelées par le client. Si la propriété n'est pas définie, ces méthodes exportées ne peuvent être appelées qu'à partir des méthodes serveur (à la fois les méthodes des modules communs du serveur et les méthodes serveur du module de formulaire et des modules de commande).
Conseil . Il est recommandé de définir la propriété Server Invocation sur False dans les cas où le module commun côté serveur contient des méthodes que vous ne souhaitez pas appeler depuis le client (pour des raisons de sécurité, par exemple).
Note. Si les propriétés sont définies en même temps Client (application régulière), Client (application gérée), Jointure externe, la propriété Call Server est automatiquement réinitialisée. Si la propriété Serveur d'appel est définie, les propriétés sont automatiquement réinitialisées Client (application régulière), Client (application gérée) Et Jointure externe si ces propriétés ont été définies en même temps.
Propriété Privilégié est conçu pour désactiver le contrôle d'accès lors de l'exécution des méthodes d'un module commun.
NOTE. Si la propriété Privilégié est définie, la propriété Server est automatiquement définie pour le module commun et les autres propriétés sont réinitialisées ( Client (application régulière), Client (application gérée) et B connexion externe). Un module partagé privilégié ne peut s'exécuter que sur le serveur.

Réutilisation des valeurs de retour

Si le module partagé n'est pas global, alors la propriété Réutiliser les valeurs de retour devient disponible. Cette propriété peut prendre les valeurs suivantes :
● Ne pas utiliser - Les valeurs de retour ne sont pas réutilisées pour les fonctions de ce module partagé.
● Par appel et par session - Le module partagé utilise la méthode de détection de réutilisation des données. L'essence de cette méthode réside dans le fait que lors de l'exécution du code, le système se souvient des paramètres et du résultat des fonctions après le premier appel de fonction. Lorsque la fonction est appelée à nouveau avec les mêmes paramètres, la valeur stockée est renvoyée (du premier appel) sans exécuter la fonction elle-même. Si la fonction modifie les valeurs des paramètres lors de son exécution, le fait d'appeler à nouveau la fonction ne le fera pas.
Les fonctionnalités suivantes d'enregistrement des résultats d'appel peuvent être distinguées :
● si la fonction est exécutée sur le serveur et appelée depuis le code du serveur, alors les valeurs des paramètres et le résultat de l'appel sont mémorisés pour la session en cours côté serveur ;
● si la fonction est exécutée sur un client lourd ou léger, alors les valeurs des paramètres et les résultats des appels sont stockés côté client ;
● si la fonction est exécutée côté serveur et appelée depuis le code client, alors les valeurs des paramètres d'appel sont mémorisées aussi bien côté client que côté serveur (pour la session en cours).
Les valeurs stockées sont supprimées :
● si la propriété est définie sur Pendant la durée de l'appel :
● côté serveur – lorsque le contrôle est rendu par le serveur ;
● côté client – ​​lorsqu'une procédure ou fonction 1C:Enterprise de niveau supérieur se termine (appelée par le système depuis l'interface, et non depuis une autre procédure ou fonction 1C:Enterprise) ;
● si la propriété du module partagé est définie sur Pendant la durée de la session :
● côté serveur – à la fin de la session ;
● côté client – ​​lorsque l'application client est fermée.
Les valeurs enregistrées seront supprimées :
● sur le serveur, dans le client lourd, dans la connexion externe, dans le client léger et dans le client Web avec vitesse normale connexions - 20 minutes après le calcul de la valeur stockée ou 6 minutes après la dernière utilisation ;
● dans un client léger et un client Web à faible vitesse de connexion - 20 minutes après le calcul de la valeur stockée ;
● lorsqu'il y a un manque de RAM dans le processus de travail du serveur ;
● lors du redémarrage d'un workflow ;
● Lorsqu'un client passe à un flux de travail différent.
Après suppression des valeurs, l'appel à la fonction exportée est effectué comme lors du premier appel.
Pour effectuer des démarches propriété donnée les modules communs ne sont pas affectés - les procédures sont toujours exécutées.

Si un module partagé a un ensemble de réutilisation de valeur de retour, il existe un certain nombre de restrictions sur les types de paramètres de la fonction exportée. Les types de paramètres ne peuvent être que :
● Types primitifs ( Non défini, NULL, Booléen, Nombre, Chaîne, Date).
● Toute référence à des objets de base de données.
● Structures avec des valeurs de propriété des types ci-dessus. Dans ce cas, l'identité des paramètres est contrôlée "par le contenu" des structures.
Si la fonction exportée renvoie un objet, elle renvoie en fait une référence à l'objet stocké dans le cache. Si l'état de l'objet change après avoir reçu cette référence, un appel ultérieur à la même fonction renverra une référence à l'objet déjà modifié sans réellement exécuter la fonction. Ce comportement se poursuivra jusqu'à ce que la valeur stockée soit supprimée (pour une raison quelconque). En d'autres termes, la modification de l'état d'un objet obtenu à la suite de l'appel d'une fonction à partir d'un module partagé avec réutilisation des valeurs de retour n'est pas la base pour appeler réellement la fonction. Gardez également à l'esprit que le cache d'objets renvoyé est indifférent à
état du mode privilégié au moment de l'appel de la fonction avec valeurs de retour réutilisées. Cette fonctionnalité peut entraîner le comportement suivant :
● L'exécution réelle de l'appel de fonction avec réutilisation de la valeur de retour (le premier appel) a été effectuée avec le mode privilégié activé.
● Lors de l'exécution d'une fonction, un objet a été reçu qui ne peut pas être reçu avec le mode privilégié désactivé.
● Des appels ultérieurs à la fonction ont été effectués sans définir le mode privilégié.
● Cependant, jusqu'à ce que le cache des objets renvoyés soit vidé ou que l'appel réel soit effectué à nouveau, la fonction renverra un objet formellement inaccessible.
● Le comportement inverse est également vrai, où le premier appel est effectué sans définir le mode privilégié, et le mode privilégié ne renvoie pas un objet qui aurait pu être obtenu en mode privilégié.

Si le module commun a une propriété Réutilisation des valeurs de retour est défini sur Pendant toute la durée de la session, alors les valeurs renvoyées par les fonctions d'un tel module ne peuvent pas utiliser de valeurs de type Gestionnaire de tables temporaires.
Si une fonction d'un module partagé, avec un ensemble de réutilisation, est appelée depuis le même module partagé (par exemple, avec le nom SharedModule ), alors vous devez vous souvenir de la caractéristique suivante : si la fonction est appelée par le nom MyFunction() , alors la fonction sera exécutée à chaque appel de la fonction. Pour utiliser des valeurs stockées, la fonction doit être appelée par son nom complet :
GeneralModule.MaFonction().
La méthode de contexte global supprime toutes les valeurs réutilisées, à la fois côté serveur et côté client, quel que soit l'endroit où la méthode est appelée. Après avoir exécuté la méthode UpdateReusableValues() le premier appel de fonction sera exécuté complètement.