Modules généraux. Les données du projet des modules communs peuvent être saisies dans le système de plusieurs manières
Imprimer (Ctrl+P)
Les objets situés dans la branche Modules généraux de l'arbre de configuration sont destinés à contenir les textes de fonctions et de procédures appelables depuis tout autre module de configuration.
ATTENTION! Un module général ne peut contenir que des définitions de procédures et de fonctions.
Les procédures et fonctions d'un module commun pour lesquelles le mot-clé Export est spécifié dans leurs en-têtes sont l'une des composantes du contexte global. Plus d'informations sur les procédures d'écriture dans un module général peuvent être trouvées dans les sections « Format des textes sources des modules de programme » et « Opérateurs » de l'aide du langage intégré.
Pour éditer un module commun, dans la palette des propriétés d'un objet de type Modules communs dans la fenêtre Configuration, dans la propriété Module, cliquez sur le lien Ouvrir. Le texte du module général sera publié pour édition dans l'éditeur de texte du système 1C:Enterprise dans le mode d'édition de texte du module logiciel.
Le module commun, faisant partie de la configuration, est enregistré uniquement dans le cadre de la configuration.
La propriété Global détermine si les méthodes exportées d'un module commun font partie du contexte global.
Si la propriété Global est définie sur True, alors les méthodes exportées du module commun 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 un nom qui correspond au nom du module commun dans les métadonnées. Cette propriété est en lecture seule. La valeur de cette propriété est l'objet GeneralModule. Les méthodes exportées de ce module commun sont disponibles via cet objet. 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:
Travailler AVEC des équipements de vente au détail.ConnectBarcode Scanner();
Contexte divers et modules communs
À l'aide des propriétés des modules communs et des instructions du préprocesseur, vous pouvez organiser l'exécution de diverses méthodes de modules communs dans le contexte souhaité.
Chaque propriété d'un module commun est responsable de la capacité à compiler (et 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 général sont disponibles :
● Client (application régulière)– les méthodes du module commun seront disponibles pour le client lourd en mode application normal ;
● – les méthodes du module général seront disponibles pour le client léger, le client web, ainsi que 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 commun seront disponibles dans plusieurs contextes.
Si un module commun a la propriété Serveur et toute autre propriété définie, cela signifie que le module commun sera disponible simultanément sur le serveur et dans le client sélectionné. Il faut comprendre qu'en fait il s'agira de plusieurs versions du code compilé (en fonction du nombre de clients sélectionnés et du serveur lui-même).
De plus, si une méthode située dans un tel module commun est appelée côté client, alors la copie client du module commun sera utilisée, et si depuis le serveur, la copie serveur. Dans ce cas, à l'aide des directives du préprocesseur (voir ici pour plus de détails), vous pouvez « protéger » le serveur du code qui ne peut pas y être exécuté.
Regardons un exemple. Dans le module commun (qui peut être exécuté sur le 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 ThinClient Alors
// Afficher l'avertissement
Afficher l'alerte utilisateur(«Sur le client»);
#Fin si
Fin de la procédure
Ensuite côté serveur le code ressemblera à ceci :
Procédure Méthode CommonModule() Exporter
// Divers codes importants vont ici
Fin de la procédure
Et côté client léger, le code ressemblera à ceci :
Procédure CommonModule Method() Exporter
// Divers codes importants vont ici
// Afficher l'avertissement
ShowUserAlert("Sur le client");
Fin de la procédure
Il existe plusieurs manières de transférer le contrôle du client vers le serveur :
● appeler la méthode du module commun du serveur ;
● dans un formulaire ou un module de commande, appeler une méthode précédée de directives de compilation &SurServeur, &SurServeurSans contexte
Dans le même temps, il est impossible d'appeler les méthodes des modules communs client (pour lesquels la propriété Serveur n'est pas définie) et les 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 de la méthode du serveur le plus externe terminé.
L'exception concerne les méthodes du module form et du module command, qui sont précédées de directives de compilation. &SurClientSurServeur, &SurClientSurServeurSans contexte
Les points suivants doivent également être mentionnés :
● Si un module commun est disponible pour plusieurs clients, alors lors de l'écriture du code du programme, vous devez tenir compte des restrictions maximales pouvant être imposées par les clients, ou utiliser les instructions du préprocesseur pour « isoler » le code spécifique au client.
● Les instructions du préprocesseur ont également un sens lorsqu'un module commun a plusieurs contextes d'exécution, par exemple une connexion externe et un client léger, ou (ce qui est beaucoup plus courant) un client et un serveur. Dans ce cas, les instructions du préprocesseur encadreront du code interactif qui ne pourra pas être utilisé sur le serveur, mais pourra être utilisé sur le client (voir 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 du langage intégré.
La propriété Call Server est destinée à contrôler la possibilité d'appeler les méthodes exportées du module commun du serveur à partir du code client.
Si la propriété est définie, les méthodes exportées du module commun du serveur sont disponibles pour appel depuis le client. Si la propriété n'est pas définie, ces méthodes exportées ne peuvent être appelées qu'à partir de méthodes côté serveur (à la fois les méthodes des modules communs côté serveur et les méthodes côté serveur des modules de formulaire et des modules de commande).
Conseil . Il est recommandé de définir la propriété Server Call sur False dans les cas où le module commun du serveur contient des méthodes que vous ne souhaitez pas appeler depuis le client (par exemple, pour des raisons de sécurité).
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é du serveur d'appel 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 destiné à désactiver le contrôle des droits d'accès lors de l'exécution des méthodes d'un module commun.
NOTE. Si la propriété Privilégié installé, la propriété Serveur est automatiquement définie pour le module commun et les propriétés restantes 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 être exécuté que sur le serveur.
Réutilisation des valeurs de retour
Si le module partagé n'est pas global, la propriété Réutiliser les valeurs de retour devient disponible. Cette propriété peut prendre les valeurs suivantes :
● Ne pas utiliser - Il n'y a pas de réutilisation des valeurs de retour pour les fonctions de ce module commun.
● Par appel et par session – Le module partagé utilise une méthode pour déterminer la réutilisation des données. L'essence de cette méthode est que lors de l'exécution du code, le système mémorise les paramètres et le résultat des fonctions après le premier appel de la fonction. Lorsqu'une fonction est à nouveau appelée avec les mêmes paramètres, la valeur stockée (du premier appel) est renvoyée sans exécuter la fonction elle-même. Si une fonction modifie les valeurs des paramètres lors de son exécution, un nouvel appel à la fonction ne le fera pas.
Les fonctionnalités suivantes de sauvegarde des résultats des appels peuvent être mises en évidence :
● si une fonction est exécutée sur le serveur et appelée à partir du 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 de l'appel sont mémorisés côté client ;
● si une 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 à la fois côté client et côté serveur (pour la session en cours).
Les valeurs enregistrées sont supprimées :
● si la propriété est définie sur Pendant la durée de l'appel :
● côté serveur – lors du retour du contrôle depuis le serveur ;
● côté client – lorsqu'une procédure ou une fonction du langage intégré de niveau supérieur se termine (appelée par le système depuis l'interface, et non depuis une autre procédure ou fonction du langage intégré) ;
● si la propriété du module partagé est définie sur Pour la durée de la session :
● côté serveur – à la fin de la session ;
● côté client – lors de la fermeture de l'application client.
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 une vitesse de connexion normale - 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 avec une faible vitesse de connexion – 20 minutes après le calcul de la valeur enregistrée ;
● s'il y a un manque de RAM dans le processus de travail du serveur ;
● lors du redémarrage du workflow ;
● lorsque le client passe à un autre workflow.
Une fois les valeurs supprimées, l'appel à la fonction exportée est effectué comme lors du premier appel.
Cette propriété des modules communs n'affecte pas l'exécution des procédures - les procédures sont toujours exécutées.
Si un module commun est configuré pour réutiliser les valeurs de retour, un certain nombre de restrictions sont imposées sur les types de paramètres exportés par la fonction. Les types de paramètres ne peuvent être que :
● Types primitifs ( Indé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, après avoir reçu cette référence, l'état de l'objet change, alors un appel ultérieur à la même fonction renverra une référence à l'objet déjà modifié sans exécuter réellement la fonction. Ce comportement continuera jusqu'à ce que la valeur stockée soit supprimée (pour quelque raison que ce soit). En d'autres termes, changer l'état d'un objet résultant d'un appel de fonction depuis un module commun avec réutilisation des valeurs de retour n'est pas la base de l'appel de fonction proprement dit. N'oubliez pas non plus que le cache des objets renvoyés est indifférent à
état de mode privilégié au moment où la fonction est appelée, en réutilisant les valeurs de retour. Cette fonctionnalité peut conduire au comportement suivant :
● L'exécution réelle de l'appel de fonction avec réutilisation des valeurs de retour (le premier appel) a été réalisé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é.
● Les 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 lorsque le premier appel est effectué sans définir le mode privilégié et qu'en mode privilégié, un objet qui aurait pu être reçu en mode privilégié n'est pas renvoyé.
Si un module commun a la propriété Réutilisation des valeurs de retour est défini sur Pendant la durée de la session, alors les valeurs du type ne peuvent pas être utilisées dans les valeurs renvoyées par les fonctions d'un tel module Gestionnaire d'horaires.
Si une fonction d'un module partagé, avec une réutilisabilité définie, est appelée depuis le même module partagé (par exemple, nommé GeneralModule), alors la mise en garde suivante doit être gardée à l'esprit : si la fonction est appelée par le nom MyFunction() , alors la fonction sera exécutée à chaque fois que la fonction est appelée. Pour que les valeurs stockées soient utilisées, la fonction doit être appelée par son nom complet :
GeneralModule.MyFunction().
La méthode de contexte global supprime toutes les valeurs réutilisées, 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 UpdateReusedValues() le premier appel de fonction sera exécuté complètement.
Aujourd'hui, nous examinerons les modules courants, ce qu'ils sont, pourquoi ils sont nécessaires et comment les utiliser. Vous pouvez regrouper les fonctions utilisées dans plusieurs documents dans un module commun. Par exemple, calculer le montant dans la partie tabulaire du document.
Par exemple, prenons notre ancienne configuration, que j'ai utilisée dans les articles précédents. Nous y avons deux documents : l'arrivée des marchandises à l'entrepôt et la libération des marchandises à l'entrepôt. Les deux documents comportent des procédures qui calculent le montant dans une ligne tabulaire.
Chaque document contient le même code de calcul du montant.
Procédure MaterialsPriceOnChange (Element)
Ligne TabularPart = Elements.Materials.CurrentData ;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price ;
Fin de la procédure
Aujourd'hui, nous allons le déplacer vers un module commun et l'appeler à partir du document.
Nous créons un module général de calcul du montant
Et commençons, vous devez d’abord créer un module commun. Pour ce faire, allez dans le configurateur, recherchez l'élément Modules généraux, faites un clic droit et ajoutez-en de nouveaux, écrivez le nom WorkWithDocuments. Nous y entrons le code suivant.
Assurez-vous également de cocher les cases à côté de Client (application gérée) et Serveur dans la fenêtre des propriétés.
Vous devez maintenant modifier légèrement le code dans le module de formulaire de document. À gauche dans la configuration, nous recherchons le document Arrivée de marchandises, développons les fenêtres jusqu'à la fenêtre Formulaires, double-cliquez sur Formulaire de document et dans la fenêtre du formulaire qui s'ouvre, allez dans l'onglet Module en bas. Nous avons ce code
Cette procédure fonctionne lors de la modification de la quantité dans la partie tabulaire du document d'entrée de marchandises et calcule le montant.
&SurClient
Fin de la procédure
Et cette procédure commence à fonctionner lorsque le prix change dans la partie tabulaire du document d'entrée de marchandises et calcule le montant.
&SurClient
Ligne TabularPart = Elements.Materials.CurrentData ;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price ;
Fin de la procédure
Remplacez-le par celui-ci
&SurClient
Procédure MaterialsQuantityOnChange(Element)
Ligne TabularPart = Elements.Materials.CurrentData ;
Fin de la procédure
&SurClient
Procédure MaterialsPriceOnChange (Element)
Ligne TabularPart = Elements.Materials.CurrentData ;
WorkWithDocuments.CalculateSum(TabularPartRow);
Fin de la procédure
Comme vous l'avez remarqué, une seule ligne change ; à première vue, il peut sembler qu'une ligne a été remplacée par une autre. Mais n'oubliez pas que ceci est un exemple. En fait, la quantité de code peut être beaucoup plus importante si, par exemple, vous effectuez des calculs à l'aide d'une formule complexe, auquel cas le code sera sensiblement réduit.
Nous faisons de même pour le document Sortie des marchandises de l'entrepôt, exécutons et vérifions la fonctionnalité du code. Vous et moi avons donc réalisé le premier module commun, j'espère que mon article sera utile à quelqu'un.
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 jeux 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))
L'article poursuit la série « Premiers pas du développement sur 1C », il aborde en détail les questions suivantes :
- Qu'est-ce qu'un module logiciel et de quelles sections se compose-t-il ?
- A quoi sert le module applicatif ? Pourquoi y en a-t-il deux ? Quand commence-t-il ? Quelles sont les subtilités du travail ?
- Quels événements sont associés au démarrage du système, comment et où les traiter ?
- A quoi sert le module de connexion externe ? Quand et comment l'utiliser ?
- Quand le module de séance est-il utilisé ?
- Quels sont les modules communs ? Quelles sont ses propriétés et ses règles de fonctionnement ? Pourquoi utiliser la propriété « Réutilisation des valeurs de retour » ?
- Quand le module de formulaire est-il utilisé et quels événements peuvent y être traités ?
- A quoi sert le module objet ? De quelles sections se compose-t-il ? Comment puis-je voir les événements du module disponible ?
- Quelles sont les subtilités du travail avec les modules de gestion de valeurs (pour les constantes) et les modules de jeu d'enregistrements (pour les registres) ?
- Quelles sont les différences entre un module objet et un module gestionnaire ? Quand faut-il utiliser ce dernier ?
Applicabilité
L'article traite de la plateforme 1C:Enterprise 8.3.4.496. Le matériel est également pertinent pour les versions actuelles de la plate-forme.
Modules dans "1C:Entreprise 8.3"
Les modules sont les objets qui contiennent du code de programme.
Il existe un assez grand nombre de types de modules dans la Plateforme, chacun ayant son propre objectif et ses propres fonctionnalités.
Toute ligne de code doit être dans un module. Il existe des modules à usage général et des modules objets. Certains modules peuvent être compilés à la fois sur le Client et sur le Serveur, et d'autres uniquement sur le Serveur.
Un module peut être composé de plusieurs sections. La section description des variables décrit les variables locales de ce module, qui peuvent ensuite être utilisées dans n'importe quelle procédure.
Au sein de chaque procédure, vous pouvez accéder à une variable de module. De plus, dans la procédure elle-même, il peut y avoir une autre déclaration de variable portant le même nom. Ce sera une variable locale de cette procédure.
Malgré le même nom, il s'agit de deux variables différentes : l'une est utilisée dans une procédure spécifique et l'autre est utilisée en dehors de celle-ci.
Dans certains modules, les variables peuvent avoir un emplacement de compilation (disponibilité) sur le Serveur ou le Client. Par exemple:
La section décrivant les variables est suivie d'une section de procédures et de fonctions, où sont indiquées les méthodes locales de ce module. Certains modules doivent préciser où la procédure ou la fonction sera compilée.
En principe, la directive de compilation peut être omise. Dans ce cas, la directive de compilation par défaut est Server. Cependant, pour faciliter l'analyse du code du programme, il est recommandé d'indiquer explicitement où une procédure donnée sera compilée. L'ordre dans lequel les procédures sont décrites n'a pas d'importance.
A la fin du module, après avoir décrit toutes les procédures et fonctions, il y a une section du programme principal, qui peut contenir certains opérateurs et initialiser les variables locales du module de formulaire. Cette section est exécutée lors de l'accès au module.
Ainsi, par exemple, lors de l'ouverture d'un formulaire d'élément, la section principale du programme du module de formulaire est exécutée en premier.
Il convient de noter que la section de déclaration de variable et la section du programme principal n'existent pas pour tous les modules (c'est-à-dire que ces sections ne sont pas valides dans certains modules). Une section décrivant les procédures et les fonctions peut exister dans absolument n'importe quel module.
Module applicatif
Ce module est conçu pour gérer les événements de démarrage et de fin d'application. Par exemple, lorsque vous lancez l'application, vous pouvez télécharger les taux de change depuis Internet. Lorsque vous quittez une application, vous pouvez confirmer auprès de l'utilisateur qu'il a l'intention de quitter.
Le module d'application contient également des gestionnaires spéciaux qui vous permettent d'intercepter les événements externes de l'équipement.
Il peut s'agir d'événements provenant d'un lecteur de carte magnétique ou d'un registraire fiscal. Et ces événements peuvent également être traités d'une manière ou d'une autre.
Veuillez noter que c'est le démarrage interactif du système qui est surveillé dans le module applicatif.
Le module applicatif ne fonctionnera pas si le programme 1C est lancé, par exemple, en mode connexion com. Dans ce cas, la fenêtre du programme n'est pas créée.
Il convient de noter que dans la Plateforme 8.3, il existe deux modules d'application différents : le module d'application gérée et le module d'application standard. Les événements du module d'application géré sont traités lorsque le client léger et lourd d'application gérée et le client Web sont lancés.
Module Application régulière fonctionne lors de l'exécution du client épais en mode Application régulière, qui contient l'interface de commande habituelle sous la forme Menu principal.
Si l'application s'exécute dans Géré, et en mode Application régulière, il faut alors décrire les procédures du gestionnaire comme pour le module Application gérée, et pour le module Application régulière.
Module Application gérée peut être sélectionné dans le menu contextuel du nœud de configuration racine.
Ce module peut également être ouvert depuis la palette des propriétés de l'élément de configuration racine.
Pour ouvrir un module Application régulière, vous devez vous référer aux paramètres de configuration (commande Possibilités au menu Service).
Le formulaire s'ouvrira Possibilités. Sur le marque-page Sont communs le mode d'édition de la configuration doit être spécifié Application gérée Et Application régulière.
Dans ce cas, le module Application régulière il sera également possible d'ouvrir depuis les propriétés du nœud racine.
Liste des événements pouvant être traités pour Géré Et Application régulière est le même.
Ce module peut contenir une section de déclaration de variables, une section de description de procédures et de fonctions arbitraires et une section de programme principal. Mais en plus des procédures et fonctions arbitraires, des gestionnaires d'événements spéciaux peuvent être localisés dans le module.
La liste des gestionnaires disponibles peut être consultée en appelant la liste des procédures et fonctions du module courant lorsque le module est ouvert.
La fenêtre Procédures et fonctions qui s'ouvre affiche toutes les procédures et fonctions de ce module, ainsi que les événements pour lesquels des gestionnaires n'ont pas encore été créés.
Il existe deux événements associés au démarrage du système (« avant » et « à »). Deux événements associés à l'arrêt du système (« avant » et « à »). Et aussi le traitement des événements externes (par exemple, les événements des équipements commerciaux).
Lorsqu'un gestionnaire d'événement "avant" est exécuté, l'action est considérée comme n'ayant pas encore eu lieu. Lorsque le gestionnaire d'événements « at » est exécuté, l'action est déjà terminée.
Événement Avant de démarrer le système se produit au moment du lancement d'Enterprise 8.3, mais l'application elle-même n'est pas encore apparue à l'écran. Cet événement a le paramètre suivant : Refus.
Si ce paramètre prend la valeur Vrai, l'application ne démarre pas. Événement Au démarrage du système suppose que l'action est déjà terminée, la fenêtre a déjà été créée, et dans ce cas nous pouvons, par exemple, afficher un formulaire spécial. Il n'est plus possible de refuser le lancement.
De même, avant d'arrêter le système, l'application est toujours ouverte et vous pouvez refuser de la fermer. Lorsque le système s'arrête, la fenêtre de l'application est déjà fermée. Il est uniquement possible d'effectuer des actions supplémentaires, par exemple supprimer certains fichiers ou envoyer un e-mail.
Dans le module Application gérée Les directives de compilation des procédures et des fonctions ne sont pas précisées, puisque le module est entièrement compilé côté Client. Cela signifie que dans les procédures et fonctions du module, nous ne pourrons pas accéder directement, par exemple, aux ouvrages de référence.
Si du module Application gérée devez faire un appel au serveur, alors pour cela vous devrez créer un spécial avec un drapeau .
Dans le module Application régulière Il n'y a pas de telles restrictions, puisque ce module sera compilé lors du chargement du Thick Client. Presque tous les types de données sont disponibles dans le Thick Client.
Les procédures, fonctions et variables d'un module applicatif peuvent être décrites comme des exportations.
Le module étant entièrement compilé sur le Client, cela signifie que dans les procédures client on peut accéder à cette méthode et à cette propriété.
Par exemple, vous pouvez appeler une procédure ou une fonction d'un module applicatif depuis le module formulaire d'un objet. Cependant, il est recommandé d'utiliser des modules communs pour décrire les algorithmes généraux. L'objectif principal du module d'application est de traiter le point de départ et le point final.
Par analogie avec un module applicatif, ce module est conçu pour traiter l'événement d'ouverture du programme et l'événement d'arrêt.
Contrairement au module applicatif qui s'initie au moment du lancement interactif de l'application, le module de connexion externe fonctionne en mode connexion COM, c'est-à-dire lorsqu'un objet 1C:Enterprise 8 est créé et connecté à une base de données spécifique.
Ce module comporte des événements : Au démarrage du système Et Lors de l'arrêt du système.
Le module de connexion externe peut être ouvert à l'aide du menu contextuel au niveau de l'objet de configuration racine ou de la palette de propriétés du nœud racine.
Le processus de connexion externe lui-même est un processus de travail programmatique avec la base d'informations, et non interactif. Par conséquent, vous ne pouvez pas actuellement utiliser de formulaires de dialogue ni afficher de messages d'avertissement, car il n'existe pas d'interface utilisateur.
Dans le module de connexion externe, il est possible de décrire les variables d'exportation et les méthodes d'exportation qui seront disponibles du côté où se produit l'appel externe à 1C:Enterprise 8.3.
Puisqu'il n'y a pas d'interface utilisateur dans une jointure externe, le module de jointure externe est entièrement compilé sur le serveur.
Module de séance
Ce module est nécessaire pour initialiser les paramètres de session. Les paramètres de session sont des variables globales rapides dont les valeurs sont disponibles n'importe où dans la configuration.
Vous pouvez ouvrir le module de session soit via le menu contextuel, soit via la palette de propriétés du nœud racine.
Le module de session propose un événement SettingSessionParameters.
Au démarrage de l'application, cette procédure est appelée en premier. Les paramètres de session sont nécessaires pour toute opération d'application : à la fois lorsqu'elle est lancée de manière interactive et lorsqu'elle est lancée en mode de connexion externe.
Le module de session décrit diverses actions pour initialiser les paramètres de session en fonction de différentes conditions.
Ce module, en règle générale, décrit plusieurs procédures appelées à partir de la procédure SettingSessionParameters. Par conséquent, toutes ces procédures sont séparées dans un module distinct.
Le module de session s'exécute toujours en mode privilégié. Cela signifie qu'aucune vérification des autorisations ne sera effectuée lors de l'accès à la base de données. Le module de session est compilé sur le Serveur, c'est-à-dire Il est possible d'accéder à toutes les méthodes du serveur (y compris la lecture des valeurs de la base de données).
Dans le module Session, il est possible de définir uniquement des procédures et des fonctions, c'est-à-dire il n'y a pas de section de description des variables ni de section de programme principal. Vous ne pouvez pas définir de méthodes d'exportation dans un module de session.
Si, lors du démarrage du système, il est nécessaire d'effectuer certaines actions sur le serveur, par exemple créer un élément d'un répertoire, alors, en option, il est possible d'utiliser le module de session, car il est compilé sur le serveur et est toujours exécuté de manière fiable au démarrage du système. Cependant, les points suivants doivent être pris en compte :
- procédure SettingSessionParameters est exécuté non seulement au démarrage du système, mais également lors de l'accès aux paramètres de session non initialisés. Ceux. le gestionnaire SetSessionParameters peut être appelé à plusieurs reprises pendant le fonctionnement de l'application ;
- si le nombre d'éléments dans le tableau des paramètres de session est nul (le tableau des paramètres requis a un type de données Indéfini), alors c'est le moment où l'application est lancée ;
- étant donné que le module de session fonctionne en mode privilégié et qu'il n'y aura aucune vérification des droits d'accès, vous devez travailler très soigneusement avec les objets de la base de données, car l'utilisateur peut accéder à des données qui ne doivent pas lui être fournies ;
- Au démarrage du système, on ne sait pas encore avec certitude si l'application sera lancée. Dans ce cas, des actions inutiles peuvent être effectuées dans le gestionnaire d'événements SetSessionParameters.
Ces modules représentent une description de certains algorithmes généraux, c'est-à-dire procédures et fonctions qui peuvent être appelées à partir de divers endroits.
Les méthodes logiquement liées peuvent être regroupées dans différents modules communs. Ces modules sont créés au sein de la branche Général.
Vous pouvez ajouter n'importe quel nombre de modules partagés. Pour rendre les méthodes Common Module disponibles ailleurs dans la configuration, elles doivent être définies avec le mot-clé Export. Les procédures client des modules communs seront disponibles sur le client et celles du serveur sur le serveur.
Dans les modules généraux, seule la section décrivant les procédures et fonctions est disponible. Ceux. dans le module général, vous ne pouvez pas décrire des variables et vous ne pouvez pas décrire une section du programme principal.
Si une variable globale est nécessaire, vous pouvez utiliser soit des paramètres de session, soit des variables d'exportation de module d'application.
Pour les modules Général, vous pouvez définir certains paramètres qui affecteront le comportement de ce module. Si la propriété Global est définie pour un module Général, alors les méthodes d'export déclarées dans ce module seront accessibles directement de l'extérieur, sans aucune instruction supplémentaire.
Ceux. le Module général participera à la formation du contexte de configuration global.
Propriété Mondial pour les modules généraux, cela peut être utile. Cependant, vous ne devez pas l'utiliser partout pour tous les modules courants.
Ceux , qui sont marqués du signe Mondial, sera compilé au démarrage du système. Plus il y a de modules de ce type, plus le programme démarrera lentement.
Si le drapeau Mondial Pour Module général n'est pas spécifié, alors la compilation de ce module sera effectuée au moment du premier appel à celui-ci (c'est-à-dire après le démarrage du système).
De plus, l'utilisation de modules communs globaux affecte la compréhension du code. Les méthodes d'un module commun non global sont appelées via le nom Module général et le nom de la méthode, par exemple :
Module de calcul des coûts.DistributeIndirectCosts();
Dans ce cas, les noms des modules communs doivent refléter le contenu des procédures qui y sont décrites. Spécifier le nom du module commun lors de l'appel d'une procédure permet de mieux comprendre le code.
Pour Module général V Palette Propriétés vous pouvez définir la propriété Privilégié.
Le module privilégié ne contrôle pas les droits d'accès. Ceci est nécessaire si Module général Il est nécessaire d'effectuer un traitement de données de masse, en obtenant des données de la base de données.
Le contrôle des droits d'accès augmente le temps nécessaire pour accéder à une base de données et les algorithmes de masse doivent souvent fonctionner le plus rapidement possible.
Par exemple, la paie est une opération gourmande en ressources. Cela doit être fait le plus rapidement possible. Pour ce faire, les algorithmes qui calculent les salaires sont placés dans des zones privilégiées. .
Parallèlement, toutes les procédures qui garantissent l'achèvement des documents de paie sont en dehors de ces Modules communs. C'est dans ces procédures que s'effectue le contrôle des droits d'accès.
De cette manière, des améliorations significatives des performances peuvent être obtenues. Cela est particulièrement vrai lors de l'utilisation d'un mécanisme de contrôle d'accès ligne par ligne aux enregistrements de table.
Si un Module Commun est privilégié, alors les procédures de ce module ne peuvent être compilées que sur le Serveur.
Il existe des situations où certains objets doivent être inaccessibles à l'utilisateur, par exemple un certain répertoire. Mais lors de la réalisation d'un document, une référence à cet ouvrage de référence est nécessaire.
Ceux. Il est nécessaire d'étendre temporairement les droits des utilisateurs, puis de les remettre à leur état d'origine. Cet effet peut être obtenu en utilisant des Modules communs.
Pour le faire dans un cadre privilégié Module général Vous devez créer une procédure qui accède aux données requises.
Cette procédure sera appelée à partir du document correspondant. Ceux. l'utilisateur se voit effectivement accorder des droits étendus au moment où cette procédure est appelée.
Pour Modules communs Il est possible de préciser l'emplacement de compilation. Les indicateurs permettent de déterminer si le module commun sera disponible sur le client (application gérée), sur le serveur ou en mode connexion externe.
De plus, si vous basculez le mode d'édition de la configuration sur Application gérée et application régulière, alors un autre contexte de compilation sera possible - Client (application régulière).
Ainsi, il existe quatre options pour le fonctionnement du programme. Selon l'application en cours d'exécution, selon le travail sur le Client ou sur le Serveur, certains Modules Communs seront disponibles ou indisponibles.
En plus de la possibilité de spécifier des indicateurs de compilation, il est possible de spécifier des directives de compilation pour les procédures et fonctions situées dans le module commun.
Si une directive de compilation est spécifiée pour une méthode, bien que le module commun soit disponible dans tous les contextes spécifiés, la disponibilité de la méthode spécifique sera limitée par la directive de compilation.
Dans ce cas, la procédure n'est pas accessible dans un contexte qui n'est pas accessible à l'ensemble du module.
Si vous ne spécifiez pas de directive de compilation pour une procédure (fonction), elle sera compilée dans tous les contextes définis pour le module.
Ceux. Essentiellement, plusieurs copies de la procédure seront réalisées. Le choix d'une instance compilée particulière dépend de l'endroit où la procédure est appelée (par la règle d'appel la plus proche). Il faut tenir compte du fait que le code d'une telle procédure doit être écrit en tenant compte de sa disponibilité dans tous les contextes définis pour le module.
Les modules génériques accessibles simultanément dans plusieurs contextes différents sont principalement conçus pour créer des procédures accessibles dans plusieurs contextes.
Lors de la création d'un module général, il est considéré comme une bonne pratique de ne pas spécifier de directives de compilation. Ceux. La disponibilité des procédures et des fonctions doit être déterminée par les propriétés du module lui-même.
Avec cette approche, les procédures client seront situées dans des modules communs distincts et les procédures serveur seront situées dans des modules communs distincts.
Les modules dotés de plusieurs indicateurs de compilation sont extrêmement rarement utilisés dans la pratique. Voici quelques actions courantes disponibles sur le client et le serveur. Il s’agit généralement de calculs simples.
Important! Il est possible pour le Client d'accéder aux méthodes serveur d'export d'un Module Commun, mais uniquement si ce Module Commun est compilé uniquement sur le Serveur. Dans ce cas, un indicateur spécial est fourni pour permettre l'accès depuis le Client .
Pour les modules Common non globaux, il est possible de mettre en cache les valeurs renvoyées par les fonctions. Ceux. Après le premier appel d’une fonction, le système peut mémoriser le résultat de son exécution. Si cette fonction est à nouveau appelée avec les mêmes paramètres, le système renverra la valeur du cache.
Le but de ce mécanisme est d'accélérer les appels répétés. Pour configurer ce comportement, vous devez Palette Propriétés module, définissez la valeur appropriée pour la propriété Réutilisation des valeurs de retour.
Par défaut, cette propriété est définie sur Ne pas utiliser. Autres valeurs possibles : cache Pendant l'appel, ou Pendant toute la durée de la séance.
Il est logique d'utiliser cette propriété uniquement pour les fonctions dont les résultats dépendent uniquement des paramètres d'entrée. Ce mécanisme est disponible uniquement pour les modules communs non globaux.
Si la valeur du paramètre correspondant Pour la durée de l'appel est sélectionnée, le cache fonctionnera tant que la procédure à partir de laquelle la méthode Module Général a été appelée est en cours d'exécution. Si la valeur Pour la durée de la session est sélectionnée, il est alors conditionnellement supposé que le cache fonctionnera pendant que l'utilisateur travaille.
Il existe cependant certaines restrictions horaires. Le cache est automatiquement vidé 20 minutes après que la valeur entre dans le cache.
Module de formulaire
Ce module est conçu pour traiter les actions des utilisateurs. Par exemple, décrivez l'algorithme permettant à un programme de réagir lorsqu'un bouton est enfoncé. Ou, par exemple, au moment de saisir une valeur dans un champ, vérifiez immédiatement son exactitude.
En plus des événements associés aux contrôles du formulaire (boutons, champs de saisie), il existe des événements associés directement au formulaire lui-même.
Par exemple, vous pouvez gérer l'événement d'ouverture du formulaire et effectuer une initialisation initiale. Vous pouvez également gérer l'événement de fermeture du formulaire et vérifier si l'utilisateur a tout saisi correctement.
Il existe des formulaires contrôlés et des formulaires réguliers. Les modules de ces formulaires diffèrent principalement par le fait que le module de formulaire géré est clairement divisé en contexte. Chaque procédure (fonction) doit avoir une directive de compilation. Sous sa forme normale, tout le code est utilisé sur le client.
Dans un module de formulaire géré, vous pouvez déclarer des procédures et des fonctions, vous pouvez déclarer des variables et décrire une section du programme principal.
Le code du programme principal sera exécuté au moment de l'initialisation du formulaire, c'est-à-dire lorsque l'utilisateur commence à l'ouvrir. La figure montre une liste d'événements standard pour un formulaire géré.
La liste des événements d'un formulaire géré est également visible dans la liste des propriétés directement du formulaire lui-même. Cette liste est appelée dans l'éditeur de formulaires gérés.
Dans un formulaire géré, vous pouvez gérer l'événement d'écriture de l'élément. Cet événement est présent uniquement pour les formulaires objets (répertoires, documents et quelques autres). Si le formulaire n'est pas lié à un objet spécifique, il n'y a pas d'événement d'écriture.
Pour un module d'un formulaire régulier, la liste des événements standards est un peu plus petite, car Dans un formulaire géré, de nombreux événements sont amenés à être appariés (l'un est exécuté sur le client et l'autre sur le serveur). Dans sa forme normale, tout le code est exécuté sur le client.
Module objet
Ces modules sont typiques des annuaires, des documents, des plans de types de calculs, des plans comptables et bien d'autres objets. Le module objet est conçu pour gérer les événements standard. Par exemple, un événement de saisie d'un élément de répertoire, un événement d'écriture d'un élément, de suppression, de publication d'un document, etc.
En principe, l'événement write existe également dans le module Form. Mais l'événement d'écriture dans le module de formulaire se produit pendant le processus d'enregistrement interactif, lorsque vous travaillez avec un formulaire spécifique.
L'événement d'écriture dans le module objet sera exécuté sur toute écriture à partir de n'importe quelle forme de l'objet donné. De plus, si l'objet est écrit par programme, l'événement de module de l'objet se déclenchera.
Dans l'événement d'écriture du module objet, vous pouvez intégrer toutes les vérifications de l'exactitude des données en cours d'écriture, puisque cette procédure sera exécutée au moment de n'importe quel enregistrement.
Le module de cet objet peut être appelé via le menu contextuel, depuis la palette des propriétés de l'objet et depuis la fenêtre d'édition de l'objet.
La figure ci-dessous montre une liste des événements de module d'annuaire disponibles.
Dans le module objet, vous pouvez placer une section pour décrire les variables, décrivant des fonctions arbitraires qui ne peuvent pas être associées à un événement, ainsi qu'une section du programme principal.
Dans la section principale du programme, vous pouvez, par exemple, initialiser les variables locales d'un module donné. Ce code de programme sera exécuté lors de l'accès à cet objet Module.
A noter que toutes les procédures du Module Objet sont compilées sur le Serveur. Par conséquent, les directives de compilation pour les procédures et les fonctions du module objet ne sont pas requises. Certains objets de configuration n'ont pas de modules d'objet.
Cela est dû aux caractéristiques des objets eux-mêmes. Ces objets comprennent Constantes Et Registres. Pour Constante il n'y a pas de module objet, mais il existe un module très similaire appelé Module gestionnaire de valeur.
DANS Module gestionnaire de valeur vous pouvez gérer les événements d'écriture Constantes et le traitement de vérification du remplissage.
L'ensemble du contexte du module est exécuté sur le serveur.
Pour les registres, il existe un module Recordset.
Ce module a également la capacité de gérer des événements d'écriture et d'effectuer des contrôles d'occupation.
Dans les modules objet, les modules Value Manager (pour les constantes) et les modules Recordset (pour les registres), vous pouvez décrire des méthodes qui peuvent être rendues exportables, et ces méthodes seront accessibles de l'extérieur.
Ceux. En plus d'utiliser les méthodes fixes d'une classe d'objet, vous pouvez créer des méthodes supplémentaires pour un objet dans le module Objet. Ce module doit décrire la procédure correspondante avec le mot-clé Exporter.
Il sera alors possible d’accéder à cette procédure de l’extérieur. De plus, cette méthode sera affichée dans l'info-bulle contextuelle. Les nouvelles méthodes dans l'info-bulle contextuelle sont mises en évidence en bleu (icône bleue p() pour les procédures et F() pour les fonctions).
De même, vous pouvez créer une nouvelle propriété en déclarant une variable avec le mot-clé Exporter. Cette propriété est également accessible de l'extérieur.
De cette manière, il est possible d'étendre les fonctionnalités des objets (pour définir de nouvelles méthodes et de nouvelles propriétés). Cependant, les propriétés sont dynamiques et ne sont pas enregistrées dans la base de données.
Si vous devez utiliser une propriété pour un objet qui sera stocké dans la base de données, vous devez créer un attribut d'objet.
Module gestionnaire
Ce module existe pour de nombreux objets (répertoires, documents, registres, etc.). Le module s'ouvre soit via le menu contextuel de l'objet, soit via Palette Propriétés, ou via la fenêtre d'édition.
Dans le module Manager, vous pouvez remplacer certains événements standard. Par exemple, dans TraitementRéceptionSélectionDonnées, lorsqu'un élément est sélectionné dans le répertoire, un filtrage ou une vérification supplémentaire peut être effectué.
De plus, vous pouvez créer des méthodes supplémentaires dans le module Manager et indiquer qu'il s'agit de méthodes d'exportation. Dans ce cas, il est possible d’accéder à ces méthodes depuis l’extérieur.
Pour effectuer cet appel, il est nécessaire d'obtenir le type de données Gestionnaire d'annuaire.
La différence entre les méthodes d'exportation du module Manager et du module objet est que pour accéder à la méthode du module objet, vous devez d'abord obtenir l'objet lui-même (c'est-à-dire obtenir d'une manière ou d'une autre un lien puis convertir ce lien en objet) .
Après cela, les variables d'exportation et les méthodes du module objet seront disponibles. Pour le Module Manager l'appel est plus simple, par exemple :
Annuaires.Counterparties.MethodName
Ce sont deux appels différents. Convertir d'une référence en objet (méthode ObtenirObjet) est une action assez sérieuse pour le système, puisque lors de la réception d'un objet, absolument toutes les données de cet objet sont lues, ce qui peut être assez long.
La deuxième différence est que Module objet appelé dans le contexte d’un élément spécifique. On peut donc supposer qu’elle est applicable pour un élément donné (dans la plupart des cas, c’est exactement la logique utilisée).
Quant au module Manager, il décrit une action commune pour un groupe ou pour tous les éléments d'un répertoire ou d'un document. Par exemple, si vous devez imprimer un élément de répertoire, vous pouvez utiliser le module Objet.
Mais dans le module Manager, il est possible de créer un mécanisme plus universel qui imprimera, entre autres, un groupe d'éléments.
De plus, accéder à l'objet Module est toujours une action plus longue. Il est donc préférable de résoudre ce problème dans le module gestionnaire.
Ceci conclut notre connaissance des modules de la configuration du système 1C:Enterprise. Si nous résumons brièvement tout ce qui précède, l’essentiel est les conclusions suivantes :
- Un module logiciel fait partie de la configuration qui ne peut contenir que du texte dans le langage 1C intégré
- Les modules logiciels sont classés selon les types dont nous avons parlé dans cet article. Chaque vue est déterminée par son emplacement et le contexte du programme disponible.
- La structure du module se compose de plusieurs sections disposées dans un certain ordre. La composition des sections est déterminée par le type de module.
Notez également que nous avons volontairement omis un type de module, à savoir le module de commande. Cela n’a rien de remarquable, et nous vous invitons à vous familiariser avec ses fonctionnalités.
Jusqu'à présent, nous avons considéré tout notre code de programme séparément de la solution d'application et, en règle générale, nous l'avons écrit dans notre propre petite configuration de test. Savez-vous que « vous ne pouvez pas simplement y aller » et commencer à éditer le code d’une configuration standard ? Non? Alors dans le prochain article, nous vous expliquerons tout !
