Abonnements aux événements 1c 8.2 traitement de la tenue. Affectation de gestionnaires d'événements à l'aide d'abonnements aux événements. Mode d'emploi du programme "Event Study"

Lors du développement ou de la modification de solutions d'application sur la plate-forme 1C:Enterprise 8.x, il est très souvent nécessaire d'effectuer une action standard pour un groupe d'objets de configuration (par exemple, des répertoires). Afin de ne pas décrire les actions en cours d'exécution dans le module de chaque objet, le développeur peut utiliser le mécanisme de plate-forme standard - l'abonnement aux événements.

Les abonnements aux événements vous permettent d'intercepter les événements des objets de configuration, tels que les ouvrages de référence, les documents, les plans pour les types de caractéristiques, etc. Aujourd'hui, dans l'article, nous examinerons la question de la séquence d'exécution des gestionnaires d'abonnement aux événements, et analyserons également le comportement de la plate-forme lorsqu'il y a plusieurs abonnements aux événements pour une action (par exemple, lors de l'enregistrement).

Comportement standard

Dans notre exemple, un répertoire "SimpleDirectory" est utilisé. Il a des abonnements aux événements pour chaque événement dans lequel un développeur peut intervenir. Les procédures de gestionnaire d'événements se trouvent dans le module commun du serveur correspondant.

L'ordre dans lequel les gestionnaires d'abonnement sont appelés est le même que dans le comportement standard de la plate-forme lors de l'utilisation d'un objet donné. Étant donné que dans notre exemple, nous envisageons de travailler avec un livre de référence, je propose de considérer le schéma d'appel des gestionnaires en fonction des actions avec un objet (voir la capture d'écran suivante).

Comme nous pouvons le voir, au stade initial, les gestionnaires d'événements "ProcessingFill" (pour créer un nouvel élément) ou "OnCopy" (pour créer un élément basé sur un élément existant) sont appelés. Dans les deux cas, après avoir appelé les gestionnaires nommés, la procédure "OnSettingNewCode" est exécutée, où le développeur peut définir un préfixe dans le code ou remplacer le comportement de la plate-forme lors de l'attribution d'un nouveau code.

Lors de l'écriture d'un élément de répertoire, qu'il s'agisse d'un nouvel élément ou d'un élément existant, trois gestionnaires sont appelés : "ProcessingFill Check" (à ce stade, le gestionnaire peut vérifier l'exactitude des données saisies et, s'il y a des erreurs, refuser de write), "BeforeWrite" (jusqu'à ce que l'objet soit écrit dans la base de données, vous pouvez ajuster les valeurs des détails et vérifier d'éventuelles conditions supplémentaires) puis "On Write" (l'enregistrement a été effectué dans la base de données, mais la transaction n'est pas fermée, le développeur peut vérifier les données après l'enregistrement et, si nécessaire, annuler la transaction).

L'événement "BeforeDeletion" se produit uniquement si l'objet est directement supprimé de l'infobase. Normalement, aucun utilisateur ne dispose de droits de suppression directs sans contrôle d'intégrité référentielle. La suppression doit toujours être effectuée par le traitement "Suppression des objets marqués". Dans ce dernier cas, le gestionnaire "BeforeDelete" est également appelé.

Ainsi, si nous créons un élément de répertoire et l'écrivons dans l'infobase, la plateforme appellera les gestionnaires d'événements suivants dans l'ordre spécifié :

Concernant les autres objets de configuration, le fonctionnement du mécanisme de souscription aux événements sera similaire, seuls les événements et leur ordre pourront différer. Voir l'assistant de syntaxe pour plus de détails.

Côté sans papiers

Considérons maintenant une situation intéressante. Disons que pour notre ouvrage de référence "SimpleCatalog" trois souscriptions à l'événement "BeforeWrite" sont définies :

Dans quel ordre pensez-vous que les gestionnaires de ces abonnements seront appelés ? Ne devinons pas. Je vais donner le résultat de l'écriture d'un élément, où le gestionnaire de chaque abonnement affiche un message avec le nom de l'abonnement appelé (voir la capture d'écran suivante).

À partir de la capture d'écran, il n'est pas difficile de deviner que l'ordre d'appel des procédures du gestionnaire d'abonnement aux événements correspond à l'ordre des objets de métadonnées dans la branche "Abonnements aux événements". Cette fonctionnalité n'est décrite dans aucune documentation de référence sur la plate-forme 1C:Enterprise, vous devez donc être prudent lors de son utilisation et dans la configuration, car des fonctionnalités non documentées peuvent changer d'une version à l'autre de 1C:Enterprise et, en même temps, peuvent ne pas figurer dans la liste des changements de programme.

Retraite

Vous demandez : "Pourquoi créer plusieurs abonnements pour un seul événement d'objet de configuration ?". La réponse est simple. Si plusieurs personnes sont impliquées dans le développement, une interférence dans les mécanismes créés les uns des autres peut entraîner un fonctionnement incorrect du programme. Dans de tels cas, il serait plus logique de créer des abonnements aux événements distincts pour chaque développeur en fonction de la tâche. Bien sûr, il est possible qu'à l'avenir, ils soient fusionnés en une seule procédure de traitement.

Cet article est une annonce de nouvelles fonctionnalités.
Il n'est pas recommandé d'utiliser le contenu de cet article pour apprendre de nouvelles fonctionnalités.
Une description complète de la nouvelle fonctionnalité sera fournie dans la documentation de la version respective.
La liste complète des modifications de la nouvelle version est donnée dans le fichier v8Update.htm.

Implémenté dans EDT version 1.7.0.567.

Dans 1C:Enterprise Development Tools (EDT), nous avons implémenté un prototype d'un nouvel outil. Le titre de travail de cet outil est Editor Tous les abonnements aux événements. Il vous aidera à analyser facilement les abonnements à tous les événements qui existent dans la solution d'application.

Abonnements aux événements

La plateforme 1C:Enterprise vous permet de créer des abonnements aux événements des objets de configuration dans une solution applicative. Une souscription est une procédure qui sera exécutée après l'exécution du gestionnaire d'événements d'origine. La commodité des abonnements réside dans le fait qu'une même procédure peut être « abonnée » à un événement appartenant à différents objets de configuration. Ainsi, s'il existe un algorithme qui doit être exécuté à la fois lors de l'enregistrement d'une organisation et lors de l'enregistrement d'un service, il peut être placé dans un abonnement, et vous n'avez même pas besoin de modifier les gestionnaires de cet événement dans les objets eux-mêmes. .

Il s'avère que l'abonnement est un mécanisme pratique et universel. Mais dans les grandes solutions applicatives, le nombre d'abonnements aux événements peut atteindre plusieurs centaines. Il devient gênant de les analyser dans l'arbre de configuration, dans une liste linéaire. Par exemple, dans la solution appliquée 1C : Gestion d'entreprise (ERP) plus de 340 abonnements à des événements.

EDT facilite un peu le travail avec les abonnements en les affichant dans le panneau Schème lorsque le module de n'importe quel objet d'application est ouvert.

Cet affichage des abonnements est pratique pour un certain nombre de tâches liées à l'édition des modules. Mais cela n'est toujours pas adapté lorsque vous devez trouver et analyser rapidement tous les algorithmes qui sont exécutés dans les abonnements lorsqu'un événement se produit.

Tous les abonnements aux événements

Pour éliminer les inconvénients énumérés ci-dessus, nous avons implémenté une manière générique de représenter les abonnements, les événements, les objets de configuration et les procédures qui implémentent des algorithmes d'abonnement.

En conséquence, vous pouvez appeler l'éditeur Tous les abonnements aux événements pour l'ensemble de la configuration, ou seulement pour un objet - la différence ne sera que dans la composition des données filtrées d'une manière ou d'une autre.

Sur le côté gauche, l'éditeur affiche tous les événements, et dans chaque événement, tous ses abonnements. Lorsqu'un abonnement spécifique est sélectionné, la liste des objets de configuration auxquels l'abonnement est « abonné » s'affiche en haut à droite. Et en bas à droite, le module et la procédure dans lesquels se trouve l'algorithme de souscription sont affichés. En double-cliquant sur une procédure, vous pouvez l'ouvrir dans l'éditeur de langage intégré.

Dans l'éditeur, vous pouvez analyser non seulement les abonnements individuels, mais également tous les abonnements liés au même événement. Si vous sélectionnez un événement, l'éditeur affichera tous les modules et toutes les procédures souscrites pour gérer cet événement.

Si vous appelez l'éditeur sur un objet de configuration, seuls les événements et les abonnements de cet objet seront affichés, et l'objet lui-même sera toujours surligné en rouge dans la liste des sources. Ainsi, vous pouvez vérifier rapidement, par exemple, que l'abonnement que vous choisissez fonctionne pour tous les objets de configuration qui en ont besoin.

L'invocation de l'éditeur avec une commande contextuelle (sur l'objet de configuration) permet de réduire immédiatement le nombre d'abonnements affichés dans l'éditeur. Par exemple, vous pouvez afficher les abonnements uniquement pour les événements qui sont traités dans le module objet ou dans le module gestionnaire.

De plus, l'éditeur contient un filtre universel avec lequel vous pouvez personnaliser arbitrairement la composition des objets, des événements et des procédures.

Notez qu'avec ce filtre, vous pouvez sélectionner non seulement des objets spécifiques qui sont la source d'événements, mais également des ensembles de types, tels que DirectoryObject, DocumentObject et d'autres. Ces ensembles de types incluent tous les répertoires ou tous les documents qui se trouvent dans la configuration.

Avec une recherche par chaîne, vous pouvez trouver rapidement uniquement les abonnements qui s'appliquent au moteur qui vous intéresse.

A tout moment, vous pouvez rapidement filtrer le contenu en fonction de l'événement ou de la source affiché dans l'éditeur. Par exemple, vous avez trouvé un abonnement Vérifier le calcul de la formule. Sa source est le plan des types de calcul Détient.

A l'aide de la commande contextuelle sur le plan des types de calcul, vous pouvez visualiser rapidement uniquement les abonnements associés à ses événements.

Ajout automatique de points d'arrêt

Une manière courante d'analyser les abonnements aux événements consiste à afficher séquentiellement toutes les procédures appelées dans le débogueur dans l'ordre dans lequel elles ont été exécutées. Pour ce faire, l'éditeur fournit un outil pratique pour ajouter automatiquement des points d'arrêt aux gestionnaires.

Tout d'abord, vous pouvez appeler cet outil directement dans l'éditeur.

Vous pouvez rechercher et sélectionner l'objet qui vous intéresse, sélectionner l'un de ses événements et marquer, par exemple, tous les gestionnaires. Après avoir appuyé D'ACCORD les points d'arrêt seront ajoutés à la première ligne exécutable de chaque gestionnaire coché, et tous ces points d'arrêt apparaîtront dans le panneau Points d'arrêt En perspective Débogage.

Une autre façon d'ajouter des points d'arrêt est pratique lorsque vous avez déjà trouvé l'objet ou l'événement qui vous intéresse dans l'éditeur. Dans ce cas, vous pouvez appeler la commande qui vous convient depuis le menu contextuel.

Et enfin, la troisième méthode que vous pouvez utiliser consiste à ajouter automatiquement des points d'arrêt déjà en cours de débogage. Dans ce cas, vous n'avez pas besoin d'ouvrir l'éditeur, car la commande d'ajout se trouve directement dans le panneau Points d'arrêt.

Alors l'éditeur Tous les abonnements aux événements est un outil polyvalent qui vous permet d'utiliser une variété de scénarios d'analyse. Il sera utile non seulement aux développeurs qui connaissent bien la solution appliquée, mais également aux spécialistes de la mise en œuvre ou aux informaticiens qui doivent gérer des fonctionnalités inconnues.

Au cours de la résolution de diverses tâches d'utilisateurs, il devient parfois nécessaire de soumettre des mouvements de documents déjà formés (à savoir, certains ensembles de registres) à une sorte d'ajustement.

À ces fins, l'objet «Abonnement aux événements» est très approprié, ce qui vous permet d'effectuer certaines actions lorsqu'un certain événement se produit pour un grand nombre d'objets (par exemple, lors de l'enregistrement de documents de paiement ou lors de la définition d'un nouveau nombre de répertoires liés à comptabilité fiscale).

De plus, s'abonner à un événement est pratique car il permet d'effectuer diverses actions sans modifier les mécanismes typiques décrits dans les différents modules.

Par exemple, une tâche s'est posée - il est nécessaire d'enregistrer certaines données (informations sur les activités de l'entreprise) dans les documents de paiement après la formation des principaux mouvements du document (formés dans l'événement "Traitement"). La tâche sera implémentée sur la configuration "Manufacturing Enterprise Management" ed. 1.3.

Regardons la solution plus en détail :

Créons un nouvel abonnement à l'événement "Enregistrer le sens de paiement". Un abonnement a un certain nombre de propriétés qui détermineront son comportement :

Source est un objet (par exemple, un document ou une liste de documents) pour lequel l'action sera appelée. Pour notre cas, nous choisissons Ordre de paiement sortant et Ordre de paiement entrant

Événements- l'action elle-même, après quoi notre code sera exécuté. Selon les conditions du problème, on choisit Traitement

Gestionnaire- une indication de la procédure dans laquelle le traitement aura lieu. A ces fins, nous choisissons le module général Usage général.

Après les objectifs ci-dessus, une procédure est créée dans laquelle il est nécessaire de placer un code pour remplir les données sur la direction (en supposant que ces informations soient déjà contenues dans les ordres de paiement).

Considérez ses paramètres:

Source- cet objet de type DirectoryObject ou DocumentObject pour lequel l'action a lieu.

Refus- un paramètre qui permet d'annuler la publication d'un document sous certaines conditions.

Mode maintien- des options de conduite (opérationnelles ou non opérationnelles), permettant de construire des algorithmes de traitement de différentes manières.

Arrêtons-nous au paramètre Source. Pour notre tâche, le type de ce paramètre sera - DocumentObject. Une collection est disponible pour ce type mouvements A qui contient tous les ensembles d'enregistrements de registre pour lesquels ce document est le bureau d'enregistrement.

Cette collection contient un ensemble d'enregistrements RèglementsAvec des contrepartiesDéfinir des enregistrements qui nous intéresse. Supposons que la dimension Direction est créée dans le registre, que nous devons remplir à partir du document.

Écrivons le code suivant :

Ensembles = Source. mouvements; Calculs = Ensembles. Règlements avec les entrepreneurs ; Pour chaque page de la page du cycle de calculs. Sens = Source. Direction; Fin si ;

Comme nous pouvons le voir, la mise en œuvre est assez simple, après avoir traité l'action pour écrire l'ensemble, vous n'avez pas besoin d'effectuer d'action supplémentaire - l'abonnement à l'événement est effectué dans le cadre de la transaction d'événement ProcessingPerforming, après son achèvement l'ensemble sera écrit automatiquement.

Les avantages de cette approche : traitement des données en dehors des algorithmes standard, réduction du travail de recherche et de transfert des modifications lors des mises à jour, meilleure visibilité - tout le code en une seule procédure.

Inconvénient de cette approche : une augmentation du temps de réalisation des documents et d'enregistrement des éléments des répertoires.

J'espère que ces informations seront utiles à la fois aux programmeurs novices et à leurs collègues plus expérimentés en tant qu'extension de leurs horizons.

Lorsqu'un utilisateur effectue des actions, la plate-forme 1C génère des événements de programme. En règle générale, pas un événement n'est généré, mais toute une chaîne d'événements. La tâche du programmeur est de placer correctement le code du programme dans les événements afin d'obtenir le comportement attendu du programme. Cependant, il ne sera pas facile pour un programmeur 1C novice de le faire, pour les raisons énumérées ci-dessous.

Les événements peuvent être générés sous une forme gérée : OnReadOnServer, OnCreateOnServer, OnOpen, etc.

Les événements dans un formulaire géré sont générés sur le client et sur le serveur : BeforeWrite, BeforeWriteOnServer.

Les événements sont appelés dans différents modules : ItemForm, ObjectModule, ManagerModule.

Certains événements peuvent être appelés plusieurs fois s'il y a plusieurs éléments de référence dans la liste, par exemple : ProcessingViewReceiving.

Un formulaire géré peut être ouvert à la suite de l'exécution de différentes actions de l'utilisateur, tandis que les chaînes d'événements d'appel seront différentes. Pour chacune des actions suivantes de l'utilisateur avec le répertoire, un formulaire géré sera ouvert : création d'un nouvel élément, copie d'un élément, modification d'un élément existant du répertoire.

Les événements sont également générés par les éléments de formulaire : lorsqu'une ligne est ajoutée à une section tabulaire, lorsqu'une ligne dans une section tabulaire est modifiée, lorsqu'une ligne ou un champ est activé, lorsqu'un élément de recherche est sélectionné dans le champ de saisie, etc.

Pour mieux comprendre la logique et la séquence des événements déclenchés, vous pouvez utiliser le développement "Event Study" joint à cet article. Connaissant le contexte de l'événement, la séquence des événements et les actions que l'utilisateur effectuera, il sera plus facile de comprendre quel gestionnaire d'événements est le mieux placé pour placer son code de programme.

Mode d'emploi du programme "Event Study"

Le programme "Event Study" montre les événements que la plateforme 1C génère lors d'actions interactives de l'utilisateur. Le principe de fonctionnement est le suivant, l'utilisateur ouvre le répertoire, le programme affiche une chaîne d'événements. L'utilisateur marque un élément de répertoire pour suppression, le programme affiche une séquence d'événements qui se produisent. Les événements sont affichés avec un court délai par défaut de 3 secondes, ceci est nécessaire pour séparer une chaîne d'événements d'une autre chaîne d'événements. Par conséquent, vous devez effectuer des actions interactives « lentement ».

Tous les événements sont affichés dans une fenêtre spéciale "Derniers événements". Il vous permet d'activer ou de désactiver l'enregistrement des événements. Par défaut, lorsque vous l'ouvrez pour la première fois, la journalisation des événements est activée. Je vous conseille de fixer la fenêtre "Derniers événements" en bas de l'écran dès le démarrage du programme, pour une visualisation pratique des événements.

Le programme lui-même ne peut pas déterminer quelle action a provoqué la chaîne d'événements, je vous conseille de taper les noms de vos dernières actions au clavier dans le champ "Raison de l'action", par exemple, "Le formulaire de la liste des répertoires est ouvert", "Un élément dans la liste des répertoires est marqué pour suppression », etc. Cela facilitera l'analyse ultérieure des actions et des événements.

Les événements sont enregistrés et affichés pour les objets placés dans la section Traçage des événements, à condition que l'enregistrement des événements soit activé dans le formulaire Événements récents.

Tous les événements enregistrés peuvent être visualisés via le "Rapport d'événement", qui se trouve dans la section "Service".

Pour effacer rapidement toutes les actions et événements enregistrés dans la section "Service", sélectionnez "Effacer les événements et actions".

Le mécanisme d'abonnement aux événements est conçu pour affecter un gestionnaire d'événements à un ou plusieurs objets de configuration 1C:Enterprise. L'article traite de plusieurs exemples d'application de ce mécanisme. Après avoir lu l'article, vous apprendrez :

• Qu'est-ce qu'un abonnement événementiel et comment l'utiliser en pratique ?
• Comment vérifier la duplication du nom lors de l'écriture d'un élément de répertoire sans modifier les modules du répertoire lui-même ?
• Comment, à l'aide d'un abonnement à un événement, assurer la formation de mouvements dans le registre d'accumulation lors de la publication d'un document ?
• Comment assurer la substitution de la forme principale du document ?

Applicabilité

L'article traite de la plateforme 1C:Enterprise, version 8.3. Les informations fournies sont pertinentes pour les versions actuelles de la plate-forme.

Abonnements aux événements

L'article traite de plusieurs exemples d'utilisation de l'un des objets auxiliaires de la plate-forme 1C: Enterprise 8 - abonnements aux événements.

Les abonnements aux événements vous permettent de placer des gestionnaires externes dans des modules partagés, qui seront exécutés après l'exécution d'un gestionnaire d'événements spécifique dans un module objet ou un module gestionnaire.

Où non requis apporter des modifications au module objet ou au module gestionnaire. Ainsi, la possibilité d'un logiciel extensions de modules sans leur modification- C'est une technique très utile lors du changement de solutions étalons.

Abonnements aux événements décrit dans le fil Sont communs fenêtres d'objets de configuration (Fig.1).

Si la configuration crée un abonnement à l'événement d'un objet, par exemple, l'événement AvantEcrit() objet document, lorsque cet événement se produit, la plateforme exécute la séquence d'actions suivante.

1. Le gestionnaire d'événements est exécuté AvantEcrit() dans le module objet document.
2. Si lors de l'exécution du gestionnaire le paramètre Refus prend la valeur Vrai ou une exception est levée, la gestion de l'événement est abandonnée.
3. Si le traitement de l'événement n'a pas été interrompu à la deuxième étape, alors les gestionnaires externes (souscriptions aux événements) définis pour l'événement sont exécutés. AvantEcrit().
4. Si lors de l'exécution du gestionnaire externe le paramètre Refus prend la valeur Vrai ou une exception est levée, l'exécution du gestionnaire externe est abandonnée.

Avec les abonnements aux événements, vous pouvez organiser effectuer diverses vérifications, qui sont exécutés lorsque des objets sont écrits dans la base de données.

Tache 1

Vérifiez la duplication du nom lors de l'écriture de l'élément du répertoire "Entrepreneurs" - sans modifier les modules du répertoire lui-même.

Pour résoudre le problème, vous devez créer un module commun EventSubscriptionHandlersEventSubscriptionHandlers. Définir le drapeau dans la palette des propriétés du module Serveur et Client (application régulière). Le deuxième indicateur est nécessaire pour que l'abonnement aux événements fonctionne dans une application normale.

Drapeau Client (application régulière) disponible si le mode d'édition est défini dans les paramètres du configurateur Application gérée vs application régulière.

En succursale Sont communs la fenêtre des objets de configuration crée un nouvel abonnement aux événements. Entrez le nom de l'abonnement dans la palette des propriétés Vérification du nom du répertoire. Dans la boîte de sélection Source marquer le type de données DirectoryObject.Contractors. Dans la boîte de sélection Événement sélectionner un événement AvantEcrit(). Après traitement de cet événement, la procédure de traitement de l'abonnement à l'événement sera déclenchée (Fig. 2).

Dans la boîte de sélection Gestionnaire le module général est spécifié, dans lequel se trouve le gestionnaire d'abonnement aux événements. Cliquez sur le bouton Ouvrir dans ce champ, sélectionnez le module EventSubscriptionHandlersEventSubscriptionHandlers et appuyez sur D'ACCORD. Le système créera automatiquement une procédure dans le module commun avec paramètres Source Et Refus. En paramètre Source l'objet pour lequel l'abonnement à l'événement est créé est transmis - DirectoryObject. . En paramètre Refus un signe de refus d'écriture de l'élément est transmis.

En procédure Vérification du nom du répertoire avant l'écriture () une requête est faite au répertoire Contreparties. Le nom de l'élément de dictionnaire enregistré est passé comme paramètre de requête Contreparties. Si un élément portant le même nom existe déjà dans la base de données, alors le paramètre Refus mis à la valeur Vrai(la saisie de l'élément est annulée) et le message de diagnostic correspondant s'affiche.

Liste des procédures Vérification du nom du répertoire avant l'écriture ()

En pratique, vous pouvez être amené à effectuer des mouvements sur des registres supplémentaires lors de l'envoi de documents dans des configurations standards. La création de registres supplémentaires permet d'éviter de modifier des registres existants et, en même temps, d'obtenir la possibilité d'un traitement supplémentaire des données lors de la réalisation de documents standards.

Tâche 2

Créer un registre de chiffre d'affaires d'accumulation "Disposition de fonds" et assurer la formation des mouvements sur ce registre lors de l'affichage du document "Ordre de caisse de dépenses" en utilisant le mécanisme de souscription d'événement.

Créer un nouveau registre du chiffre d'affaires avec le nom Cessions de trésorerie. Sélectionnez le bureau d'enregistrement "Ordre de caisse de dépenses". Ajouter des dimensions de registre :

Créer une ressource de registre :

Somme, taper Nombre, Longueur – 15, Précision – 2.

Dans le document « Bon de caisse de dépenses », créez une condition requise ArticleMouvement avec le type de données HandbookLink.ArticlesMouvements de trésorerie.

Nom - Mouvements de cession de trésorerie;
Source - DocumentObject.RKODocumentObject.RKO;
Événement - Traitement.

Dans le module général EventSubscriptionHandlersEventSubscriptionHandlers créer un gestionnaire . Le gestionnaire contourne la partie tabulaire du document "Ordre de caisse de dépenses" et génère des mouvements dans le registre d'accumulation Cessions de trésorerie.

Liste des procédures Mouvements de cession de trésorerieProcessingConducting()

Dans des configurations typiques, il peut être nécessaire d'affiner la forme principale de certains objets, comme un document. Cette tâche peut être résolue à l'aide d'abonnements aux événements. Cela crée une copie du formulaire principal du document. Les modifications nécessaires sont apportées au nouveau formulaire. En utilisant le mécanisme d'abonnement aux événements, un nouveau formulaire est ouvert à la place du formulaire principal. Dans ce cas, le formulaire principal, qui est sur support, reste inchangé.

Tâche 3

Fournir un remplacement pour le formulaire principal du document « Bon de caisse de dépenses ».

Créez un nouveau formulaire du document "Commande de dépenses en espèces" avec le nom FormulaireDocumentClient. Apportez des modifications arbitraires au formulaire, par exemple, modifiez l'ordre des contrôles. Pour appeler ce formulaire, vous devez utiliser un abonnement à un événement HandlingGettingForm() dans le module du gestionnaire de documents « Mandat sortant ».

Créez un nouvel abonnement à un événement :

Nom - Formulaire de base RKO ;
Source - DocumentManager.RKO ;
Événement - TraitementRéceptionFormulaire.

Dans le module général EventSubscriptionHandlersEventSubscriptionHandlers créer un gestionnaire . Au gestionnaire en tant que paramètre FormulaireSélectionné le nom du formulaire ouvert est passé.
Paramètre Traitement standard est réglé sur Mensonge pour désactiver l'ouverture du formulaire principal.

Liste des procédures MainFormRKOProcessingGettingForm()

Pour rechercher des abonnements aux événements définis pour un objet de configuration, vous pouvez utiliser le mécanisme de recherche de référence d'objet. Pour cela, sélectionnez un objet dans la fenêtre des objets de configuration et exécutez la commande du menu contextuel Recherche de références à un objet. À la suite de l'exécution de la commande, une liste d'objets contenant des liens vers l'objet recherché s'affichera dans la fenêtre de message de service.

Ainsi, les abonnements aux événements offrent la possibilité d'ajouter de nouvelles fonctionnalités sans modifier les modules d'objets existants. Les inconvénients des abonnements aux événements incluent :

• Augmenter la complexité des algorithmes.
• Vous ne pouvez vous abonner qu'aux événements des objets et des gestionnaires d'objets.

Si vous devez modifier un événement de formulaire, le mécanisme d'abonnement aux événements n'est pas disponible. Dans ce cas, vous devez apporter des modifications au formulaire lui-même ou copier le formulaire et apporter des modifications au nouvel objet.