Allgemeine Module 1C- ein Objekt der Konfigurationsmetadaten 1C 8.3 und 8.2, das den in der Konfiguration häufig aufgerufenen Programmcode speichert. Eine Funktion/Prozedur kann von überall in der Konfiguration aufgerufen werden (wenn sie exportiert wird).

So verwenden Sie das gemeinsam genutzte Modul

Es empfiehlt sich, eine Prozedur oder Funktion in ein gemeinsames Modul zu stellen, wenn sie an mehr als einer Stelle aufgerufen wird. Erstens, wenn ein Verfahren korrigiert wird, muss es nur an einer Stelle korrigiert werden. Zweitens wird eine größere Ordnung im Code erreicht.

Ein typisches Beispiel für ein gemeinsames Modul ist die Verarbeitung von Buchungen gemäß einem Register, das Erhalten des Betrags der Differenz in Arbeitstagen, das Umrechnen von Wechselkursen, das Neuberechnen von Menge/Preis/Betrag im Tabellenabschnitt und andere Funktionen.

Allgemeine Moduleigenschaften

Einer der Hauptunterschiede zwischen gemeinsam genutzten Modulen und anderen Modulen besteht darin, dass Sie keine gemeinsam genutzten Variablen deklarieren können.

Erhalten Sie 267 kostenlose 1C-Videolektionen:

Werfen wir einen genaueren Blick auf die Eigenschaftenpalette des gemeinsamen Moduls:

• Global- Wenn das Flag gesetzt ist, werden Funktionen und Prozeduren aus diesem Modul im globalen Kontext verfügbar. Diese. Sie können überall in der Konfiguration ohne den Namen des gemeinsamen Moduls aufgerufen werden. Allerdings wird eine Bedingung hinzugefügt – die Namen von Prozeduren und Funktionen in diesem gemeinsamen Modul müssen innerhalb des globalen Kontexts eindeutig sein.
• Server- Die Prozeduren und Funktionen dieses gemeinsamen Moduls können auf dem Server ausgeführt werden.
• Äußere Verbindung- Die Programmcodes dieses gemeinsamen Moduls können ausgeführt werden, wenn sie über eine externe Quelle (z. B. COM) verbunden sind.
• Client (verwaltete Anwendung)— Prozeduren und Funktionen dieses gemeinsamen Moduls können in einem Thick Client im verwalteten Anwendungsmodus verwendet werden.
• Kunde (reguläre Anwendung)— Die Programmcodes dieses gemeinsamen Moduls können im Thick Client im normalen Anwendungsmodus verwendet werden.
• Serveraufruf- ein Flag, das es dem Client ermöglicht, die Prozeduren und Funktionen dieses gemeinsamen Moduls zu verwenden.
• - Wenn auf True gesetzt, wird die Überprüfung der Zugriffsrechte in diesem gemeinsamen Modul deaktiviert.
• Wiederverwendung— definiert die Einstellungen für zurückgegebene Werte, wenn die Option aktiviert ist, dann merkt sich das System nach der ersten Ausführung den Wert für diese Eingabeparameter und gibt einen vorgefertigten Wert zurück. Es kann folgende Werte annehmen: Wird nicht benutzt- stilllegen, zum Zeitpunkt des Anrufs- für die Dauer eines bestimmten Verfahrens, während der Sitzung- bis der Benutzer die Sitzung (das Programm) geschlossen hat.

Wenn Sie anfangen, 1C-Programmierung zu lernen, empfehlen wir unseren kostenlosen Kurs (nicht vergessen

1.1. Gemeinsame Module werden erstellt, um Prozeduren und Funktionen zu implementieren, die nach bestimmten Kriterien kombiniert werden. In der Regel werden Prozeduren und Funktionen eines Konfigurationssubsystems (Verkauf, Einkauf) oder Prozeduren und Funktionen ähnlicher Funktionalität (Arbeiten mit Zeichenketten, allgemeiner Zweck) in einem gemeinsamen Modul untergebracht.

1.2. Beim Entwickeln gemeinsam genutzter Module sollten Sie einen von vier Codeausführungskontexten auswählen:

2.1. Gemeinsame Servermodule dienen zum Hosten von Serverprozeduren und -funktionen, die nicht für die Verwendung im Clientcode verfügbar sind. Sie implementieren die gesamte interne Server-Geschäftslogik der Anwendung.
Damit die Konfiguration in externen Verbindungsmodi korrekt funktioniert, sollten verwaltete und reguläre Anwendungen, Serverprozeduren und -funktionen in gemeinsame Module mit den folgenden Merkmalen platziert werden:

• Server(Kontrollkästchen Serveraufruf fallen gelassen),
• Kunde (reguläre Anwendung),
• Äußere Verbindung.

In diesem Fall ist gewährleistet, dass Serverprozeduren und -funktionen mit veränderlichen Typparametern aufgerufen werden können (z. B. DirectoryObject, DocumentObject usw.). In der Regel sind dies:

• Handler für Abonnements von Ereignissen von Dokumenten, Verzeichnissen usw., die einen veränderlichen Wert (Objekt) als Parameter annehmen.
• Serverprozeduren und -funktionen, denen ein Objekt als Parameter von Modulen von Verzeichnissen, Dokumenten usw. sowie von Modulen mit Ereignisabonnements übergeben wird.

Gemeinsame Servermodule werden gemäß den allgemeinen Regeln für die Benennung von Metadatenobjekten benannt.
Zum Beispiel: Arbeiten mit Dateien, Allgemeiner Zweck

In einigen Fällen kann ein Postfix hinzugefügt werden, um Namenskonflikte mit globalen Kontexteigenschaften zu vermeiden. "Server".
Zum Beispiel: ScheduledTasksServer, Datenaustauschserver.

2.2. Gemeinsame Servermodule, die vom Client aufgerufen werden sollen enthalten Serverprozeduren und -funktionen, die für die Verwendung vom Clientcode verfügbar sind. Sie bilden die Client-API des Anwendungsservers.
Solche Prozeduren und Funktionen werden in gemeinsamen Modulen mit dem Attribut platziert:

• Server(Kontrollkästchen Serveraufruf Eingerichtet)

Server-Common-Module, die vom Client aufgerufen werden sollen, werden gemäß den allgemeinen Regeln für die Benennung von Metadatenobjekten benannt und müssen mit einem Postfix benannt werden "Serveraufruf".
Zum Beispiel: Mit Dateien arbeiten, den Server anrufen

Beachten Sie, dass Exportprozeduren und -funktionen in solchen allgemeinen Modulen keine veränderlichen Typparameter enthalten dürfen ( DirectoryObject, DocumentObject usw.), da ihre Übertragung vom (oder zum) Kundencode unmöglich ist.

Siehe auch:Einschränkung beim Setzen des Flags "Serveraufruf" für gemeinsame Module

2.3. Vom Client gemeinsam genutzte Module enthalten Client-Geschäftslogik (nur für den Client definierte Funktionalität) und haben die folgenden Merkmale:

• Client (verwaltete Anwendung)
• Kunde (reguläre Anwendung)

Die Ausnahme ist, wenn Client-Prozeduren und -Funktionen nur im verwalteten Anwendungsmodus verfügbar sein sollen (nur im regulären Anwendungsmodus oder nur im ausgehenden Modus). In solchen Fällen ist eine andere Kombination dieser beiden Merkmale akzeptabel.

Gemeinsame Clientmodule werden mit einem Postfix benannt "Klient".
Zum Beispiel: WorkFilesClient, Allgemeiner Kunde

Siehe auch: Clientseitigen Code minimieren

2.4. In einigen Fällen ist es möglich, gemeinsame Client-Server-Module mit Prozeduren und Funktionen zu erstellen, deren Inhalt auf Server und Client gleich ist. Solche Prozeduren und Funktionen werden in gemeinsamen Modulen mit Funktionen platziert:

• Client (verwaltete Anwendung)
• Server(Kontrollkästchen Serveraufruf zurücksetzen)
• Kunde (reguläre Anwendung)
• Äußere Verbindung

Gängige Module dieser Art werden mit einem Postfix benannt "Kundenserver".
Zum Beispiel: WorkFilesClient, Allgemeiner ClientServer

Im Allgemeinen wird nicht empfohlen, gemeinsame Module für den Server und den Client (verwaltete Anwendung) gleichzeitig zu definieren. Es wird empfohlen, die für den Client und den Server definierte Funktionalität in verschiedenen gemeinsamen Modulen zu implementieren – siehe S. 2.1 und 2.3. Eine solche explizite Trennung von Client- und Server-Geschäftslogik wird durch Erwägungen diktiert, die Modularität der angewandten Lösung zu erhöhen, die Kontrolle des Entwicklers über die Client-Server-Interaktion zu vereinfachen und das Fehlerrisiko aufgrund grundlegender Unterschiede in den Anforderungen für die Entwicklung von Client und Server zu verringern Code (die Notwendigkeit, den auf dem Client ausgeführten Code zu minimieren, unterschiedliche Verfügbarkeit von Objekten und Plattformtypen usw.). Gleichzeitig muss die unvermeidliche Zunahme der Anzahl gemeinsamer Module in der Konfiguration berücksichtigt werden.

Ein Sonderfall von gemischten Client-Server-Modulen sind Formular- und Befehlsmodule, die speziell darauf ausgelegt sind, Server- und Client-Geschäftslogik in einem Modul zu implementieren.

3.1. Es wird empfohlen, die Namen gemeinsamer Module gemäß den allgemeinen Regeln für die Benennung von Metadatenobjekten zu erstellen. Der Name eines gemeinsamen Moduls muss mit dem Namen eines Subsystems oder eines separaten Mechanismus übereinstimmen, dessen Prozeduren und Funktionen es implementiert. Es wird empfohlen, gebräuchliche Wörter wie „Prozeduren“, „Funktionen“, „Handler“, „Module“, „Funktionalität“ usw. in den Namen gemeinsamer Module zu vermeiden. und sie nur in Ausnahmefällen anwenden, wenn sie den Zweck des Moduls besser erkennen lassen.

Um zwischen gemeinsamen Modulen eines Subsystems zu unterscheiden, die erstellt wurden, um Prozeduren und Funktionen zu implementieren, die in verschiedenen Kontexten ausgeführt werden, wird empfohlen, ihnen Postfixes zu geben, die früher in den Absätzen beschrieben wurden. 2.1-2.4.

In neuen Versionen von 1C:Enterprise-Systemkonfigurationen wurden viele Funktionen und Verfahren von Objektmodulen (Dokumente, Verzeichnisse usw.) in Managermodule verschoben. Werfen wir einen Blick auf die Unterschiede zwischen diesen beiden Modulen.

Gemäß der Theorie der objektorientierten Programmierung werden Methoden von Objekten in zwei Gruppen eingeteilt: statisch und einfach. Einfache Methoden haben nur Zugriff auf eine bestimmte Instanz der Klasse. Statische Methoden haben keinen Zugriff auf Objektdaten, sondern wirken auf die Klasse als Ganzes.

Wenn wir das alles in das 1C: Enterprise-System übersetzen, dann Objektmodul enthält einfache Methoden. Um sie zu verwenden, müssen Sie zuerst ein bestimmtes Objekt erhalten: ein Element eines Verzeichnisses, eines Dokuments usw. Manager-Modul enthält statische Methoden. Um es zu verwenden, ist es nicht erforderlich, jedes spezifische Objekt separat zu erwerben, es ermöglicht Ihnen, mit der gesamten Sammlung auf einmal zu arbeiten.

Objektmodul können Prozeduren und Funktionen haben, die extern verwendet werden können. Dazu wird eine solche Prozedur oder Funktion mit dem Wort bezeichnet Export.

Funktion NewFunction() Export

Um eine solche Funktion aus einem Objektmodul zu verwenden, müssen Sie zunächst eine Referenz auf das erforderliche Objekt haben und es mithilfe der Funktion abrufen GetObject().

Per= Objekt. Neue Funktion() ;

Ebenso können Sie neue Variablen erstellen, die von verschiedenen Konfigurationsobjekten verwendet werden können.

Variable NewVariable Export

DirectoryItem = Verzeichnisse. Nomenklatur. FindByCode("000000001" );
Objekt = Verzeichniselement. GetObject() ;
Ein Objekt. NeueVariable= ) ;

Damit ist es möglich, Standardprozeduren, Funktionen und Eigenschaften (Variablen) von Objekten zu ergänzen. Solche Variablen sind dynamisch, sie werden nicht in der Infobase gespeichert und existieren nur während der Arbeit mit dem empfangenen Objekt.

Manager-Modul hat alle die gleichen Funktionen, der einzige Unterschied besteht darin, dass Sie kein bestimmtes Objekt benötigen, um es zu verwenden. Das Manager-Modul ermöglicht es Ihnen, mit der gesamten Sammlung von Objekten eines bestimmten Typs zu arbeiten.

Prozedur NewProcedure() Export

DirectoryItem = Verzeichnisse. Nomenklatur. NeueProzedur() ;

Oder für eine Variable:

Variable NewVariable Export

DirectoryItem = Verzeichnisse. Nomenklatur. neueVariable;

Betrachten wir die Unterschiede in der Verwendung des Objektmoduls und des Managermoduls am Beispiel des Verfahrens zum Erstellen einer gedruckten Form eines Dokuments.

Bei Verwendung des Objektmoduls würde der Code so aussehen:

Funktion PrintDocument (Link) Export
// Dieser Funktion muss ein Link zu einem bestimmten Dokument übergeben werden
TabDoc zurückgeben;
Endfunktionen

Auf dem Dokumentformular müssen Sie eine Prozedur erstellen, die einen Link zum Dokument an die Druckfunktion weitergibt.

&BeiKunde
Prozedur Drucken(Befehl)
TabDoc = PrintOnServer() ;
TabDoc. Zeigen() ;
EndProzedur
&Auf dem Server
Funktion PrintOnServer()
Doc = FormAttributeToValue("Objekt" ) ;
Rücksendedokument. PrintDocument(Object. Link) ;
Endfunktionen

Der Nachteil dieser Methode ist, dass Sie nur ein Objekt drucken können. Wenn Sie mehrere Dokumente gleichzeitig drucken müssen, müssen Sie sie alle abrufen und dann die Funktion aus dem Objektmodul aufrufen. Dies erfordert erhebliche Systemressourcen, da ein empfangenes Objekt vollständig in den Arbeitsspeicher passt.

Vom Leistungsstandpunkt aus ist es viel besser, wann immer möglich das Manager-Modul zu verwenden. In unserem Beispiel sieht die Lösung des Problems so aus.
Funktion PrintOnServer()
Rücksendedokumente. UnserDokument. PrintDocument(ArrayReferenzen) ;
Endfunktionen

Bei Verwendung des Manager-Moduls kann die Druckprozedur sowohl aus dem Dokumentenformular als auch aus dem Listenformular aufgerufen werden, wobei Links zu mehreren Dokumenten im Array übergeben werden. In diesem Fall muss das System nicht jedes Dokument aus dem Array empfangen, wodurch Systemressourcen erheblich eingespart werden.

Wann sollten Sie also das Objektmodul und wann das Managermodul verwenden?

Alles hängt von der Aufgabe ab. Wenn zur Ausführung ein Verweis auf ein Objekt ausreicht (z. B. ein Druckauftrag), dann ist es besser, das Manager-Modul zu verwenden. Wenn die Aufgabe darin besteht, die Daten zu ändern, z. B. ein Dokument auszufüllen, müssen Sie es abrufen und das Objektmodul verwenden.

Die Softwaremodule enthalten ausführbaren Code in der 1C-Sprache, der notwendig ist, um auf bestimmte Weise auf die Aktionen des Systems oder Benutzers zu reagieren, wenn visuelle Entwicklungswerkzeuge nicht ausreichen. Auch in Programmmodulen können wir eigene Methoden (Prozeduren und Funktionen) beschreiben.

Typischerweise besteht ein Softwaremodul aus drei Abschnitten:

• Variablendeklarationsbereich;
• Prozedur- und Funktionsbeschreibungsbereich;
• Haupttext des Programms.

Ein Beispiel für den Aufbau eines Programmmoduls:

//******************** VARIABLE DECLARATION BEREICH *************************

Rem Nachname Export; / /Dies ist eine globale Variable
Variablenname, Patronym; //Dies ist eine Modulvariable
Namen ändern; //Dies ist auch eine Modulvariable, auf die zugegriffen werden kann

//aus jeder Prozedur und Funktion unseres Moduls

//**************** ABLAUF- UND FUNKTIONSBESCHREIBUNGSBEREICH ****************

Verfahren Verfahren1 ()
Variable Summe ; / /Total ist eine lokale Variable (Prozedurvariable)

Gesamt = Nachname + "" + Vorname + " "+ Patronym;

EndProzedur

Funktion Funktion1 ()

// Funktionsanweisungen

Return(Nachname + " " + Vorname );

Endfunktionen

//************************ PROGRAMM HAUPTTEXT ******************** *

Nachname = "Iwanow";
Name = "Iwan";
Zweiter Vorname = "Iwanowitsch";

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

In einem bestimmten Programmmodul kann einer der Bereiche fehlen.
Geltungsbereich der Variablendeklaration wird vom Anfang des Modultexts bis zur ersten Anweisung der Prozedur oder der Funktionsanweisung oder einer beliebigen ausführbaren Anweisung platziert. Dieser Abschnitt kann nur Variablendeklarationsanweisungen enthalten.

Beschreibungsbereich von Prozeduren und Funktionen wird von der ersten Anweisung einer Prozedur oder einer Funktionsanweisung bis zu jeder ausführbaren Anweisung außerhalb des Hauptteils einer Prozedur- oder Funktionsdeklaration platziert.

Textbereich des Hauptprogramms wird von der ersten ausführbaren Anweisung außerhalb des Hauptteils von Prozeduren oder Funktionen bis zum Ende des Moduls platziert. Dieser Abschnitt darf nur ausführbare Anweisungen enthalten. Der Bereich des Haupttextes des Programms wird zum Zeitpunkt der Modulinitialisierung ausgeführt. Normalerweise ist es im Hauptprogrammabschnitt sinnvoll, Anweisungen zu platzieren, um Variablen mit bestimmten Werten zu initialisieren, die vor dem ersten Aufruf der Prozeduren oder Funktionen des Moduls zugewiesen werden müssen.

Programmmodule befinden sich an den Stellen in der Konfiguration, die möglicherweise die Beschreibung bestimmter Betriebsalgorithmen erfordern. Diese Algorithmen sollten als Prozeduren oder Funktionen konzipiert sein, die in vorgegebenen Situationen vom System selbst aufgerufen werden (z. B. beim Öffnen eines Referenzformulars, beim Klicken auf eine Schaltfläche in einem Dialogfeld, beim Ändern eines Objekts usw.).

Jedes einzelne Programmmodul wird vom System als Ganzes wahrgenommen, so dass alle Prozeduren und Funktionen des Programmmoduls in einem einzigen Kontext ausgeführt werden.

Der Ausführungskontext von Modulen wird in Client- und Serverkontexte unterteilt. Zudem können einige Softwaremodule sowohl clientseitig als auch serverseitig kompiliert werden.

Anwendungsmodul (managed oder regular)

Das Anwendungsmodul beschreibt die Prozeduren (Handler) von Ereignissen, die am Anfang und am Ende des Systems initialisiert werden. Wenn Sie beispielsweise eine Anwendung starten, können Sie einige Konfigurationsdaten aktualisieren, und beim Beenden können Sie fragen, ob Sie das Programm überhaupt beenden sollen. Darüber hinaus fängt dieses Modul Ereignisse von externen Geräten wie Handels- oder Steuergeräten ab. Es ist erwähnenswert, dass das Anwendungsmodul nur im Falle eines interaktiven Starts der Anwendung ausgeführt wird, das heißt, wenn das Programmfenster gestartet wird. Dies geschieht nicht, wenn die Anwendung im Modus gestartet wird com-Verbindungen.
Es gibt zwei verschiedene Anwendungsmodule in der 1C 8-Plattform. Dies sind das Common Application-Modul und das Managed Application-Modul. Sie werden ausgelöst, wenn verschiedene Clients gestartet werden. Beispielsweise wird das Managed Application-Modul ausgelöst, wenn der Webclient gestartet wird. Dünner Kunde und Thick Client im verwalteten Anwendungsmodus. Und das reguläre Anwendungsmodul wird ausgelöst, wenn der Thick Client im normalen Anwendungsmodus gestartet wird. Die Einstellung des Anwendungsstartmodus wird in der Konfigurationseigenschaft "Hauptstartmodus" festgelegt.

Das Anwendungsmodul kann alle 3 Abschnitte enthalten – Deklarationen von Variablen, Beschreibungen von Prozeduren und Funktionen sowie den Haupttext des Programms. Das Anwendungsmodul wird auf der Clientseite kompiliert, was uns stark daran hindert, viele Arten von Daten zu verwenden. Sie können den Kontext eines Anwendungsmoduls mit den Methoden gemeinsam genutzter Module erweitern, für die die Call Server-Eigenschaft festgelegt ist. Alle Variablen und Methoden des als Export markierten Anwendungsprogrammmoduls sind in jedem clientseitigen Konfigurationsmodul verfügbar. Doch so verlockend es auch sein mag, Sie sollten hier nicht viele Prozeduren und Funktionen unterbringen. Je mehr Code in einem bestimmten Modul vorhanden ist, desto länger ist die Kompilierungszeit und folglich die Startzeit der Anwendung.

Wie oben erwähnt, handhabt das Anwendungsmodul die Start- und Endereignisse der Anwendung. Um jedes dieser Ereignisse im Anwendungsmodul zu verarbeiten, gibt es eine Reihe von Handlern Before ... und When ... Die Unterschiede zwischen ihnen sind wie folgt: Wenn der Code im Handler Before ... ausgeführt wird, hat die Aktion noch nicht erfolgt ist und wir die Ausführung ablehnen können. Dafür gibt es die Ablehnungsoption. In den On-Handlern hat die Aktion bereits stattgefunden, und wir können uns nicht weigern, die Anwendung zu starten oder zu beenden.

Externes Anschlussmodul

• kann alle 3 Bereiche enthalten
• befindet sich im Stammabschnitt der Konfiguration

Der Zweck des Moduls ist ähnlich dem Zweck des Anwendungsmoduls. Es verarbeitet die Start- und Endereignisse der Anwendung. Das externe Verbindungsmodul wird ausgelöst, wenn die Anwendung im Com-Verbindungsmodus gestartet wird. Der Outer-Join-Prozess selbst ist kein interaktiver Prozess. In diesem Modus arbeitet das Programm mit Informationsbasis und das Anwendungsfenster wird nicht geöffnet, was bestimmte Einschränkungen für die Verwendung von Methoden auferlegt, die für interaktives Arbeiten vorgesehen sind. Aufrufe von Dialogformularen, Warnungen und Meldungen an den Benutzer etc. sind in diesem Modus nicht möglich. Sie laufen einfach nicht.

Wie im Anwendungsmodul stehen hier alle drei Bereiche zur Verfügung: Variablendeklarationen, Beschreibungen von Prozeduren und Funktionen sowie der Haupttext des Programms. Der Hauptunterschied zum Anwendungsmodul besteht darin, dass im Com-Verbindungsmodus die gesamte Arbeit mit der Infobase auf der Serverseite erfolgt, sodass das externe Verbindungsmodul auf der Serverseite kompiliert wird. Dementsprechend sind Exportvariablen und Methoden gängiger Client-Module darin nicht verfügbar.

Sitzungsmodul

• serverseitig durchgeführt
• befindet sich im Stammabschnitt der Konfiguration

Dies ist ein hochspezialisiertes Modul, das ausschließlich zum Initialisieren von Sitzungsparametern entwickelt wurde. Warum mussten Sie dafür ein eigenes Modul erstellen? Seine Verwendung beruht auf der Tatsache, dass die Anwendung selbst gestartet werden kann verschiedene Modi(was bewirkt, dass entweder ein verwaltetes Anwendungsmodul, ein normales Anwendungsmodul oder ein äußeres Verbindungsmodul ausgeführt wird), und Sitzungsparameter müssen ungeachtet des Startmodus initialisiert werden. Um nicht in allen drei Modulen den gleichen Programmcode zu schreiben, brauchten wir Zusatzmodul, die unabhängig vom Startmodus der Anwendung ausgeführt wird.

Es gibt ein einziges "SetSessionParameters"-Ereignis im Sitzungsmodul, das als allererstes ausgelöst wird, noch vor dem PreSystemBegin-Ereignis des Anwendungsmoduls. Es hat keinen Variablendeklarationsabschnitt und keinen Hauptprogrammabschnitt. Und es ist auch unmöglich, Exportmethoden zu deklarieren. Das Modul wird serverseitig kompiliert.

Allgemeine Module

• kann einen Bereich zur Beschreibung von Prozeduren und Funktionen enthalten
• ausgeführt auf der Server- oder Client-Seite (abhängig von den Moduleinstellungen)
• befindet sich im Zweig der Baumstruktur der Konfigurationsobjekte "Allgemein" - "Allgemeine Module"

Allgemeine Module sollen einige allgemeine Algorithmen beschreiben, die von anderen Konfigurationsmodulen aufgerufen werden. Das allgemeine Modul enthält keine Variablendeklarationsbereiche und den Hauptteil des Programms. Darin können Sie Exportmethoden deklarieren, deren Verfügbarkeit durch die Moduleinstellungen bestimmt wird (auf welcher Seite es ausgeführt wird: auf Server- oder Clientseite). Da der Variablendeklarationsabschnitt nicht verfügbar ist, ist es nicht möglich, globale Variablen in gemeinsam genutzten Modulen zu definieren. Dazu können Sie das Anwendungsmodul verwenden.

Das Verhalten des gemeinsam genutzten Moduls hängt von den eingestellten Parametern ab (global oder nicht, verschiedene Kompilierungsflags, ob ein Serveraufruf verfügbar ist usw.). Hier sind einige Tipps zum Einrichten gemeinsam genutzter Module:

Es empfiehlt sich, das Flag „Global“ nicht überall zu verwenden. Dies verkürzt die Startzeit der Anwendung und verbessert die Lesbarkeit des Codes (natürlich, wenn das gemeinsame Modul einen vollständig aussagekräftigen Namen hat).
- Es ist nicht ratsam, mehr als ein Übersetzungskennzeichen zu verwenden. Es gibt nicht so viele Methoden, die in unterschiedlichen Kontexten durchgeführt werden müssen, und wenn solche Methoden dennoch erforderlich sind, dann kann ihnen ein separates gemeinsames Modul zugeordnet werden;
- Das Flag "Serveraufruf" ist nur sinnvoll, wenn das Modul "Auf dem Server" kompiliert wird. Daher sollten alle anderen Kompilierungs-Flags entfernt werden, um verschiedene Probleme zu vermeiden;
- Wenn in den Modulmethoden eine Massenverarbeitung von Daten, Lesen und Schreiben in die Datenbank erfolgt, ist es zur Erhöhung der Arbeitsgeschwindigkeit besser, die Zugriffskontrolle durch Setzen des Flags "Privileged" zu deaktivieren. Dieser Modus ist nur für gemeinsam genutzte Module verfügbar, die auf dem Server kompiliert wurden.

Formularmodul

• kann alle 3 Bereiche enthalten
• erfolgt server- und clientseitig

Das Formularmodul ist so konzipiert, dass es Benutzeraktionen mit diesem Formular verarbeitet (Verarbeitung des Klickereignisses auf die Schaltfläche, Änderung des Formularattributs usw.). Es gibt auch Ereignisse, die sich direkt auf das Formular selbst beziehen (z. B. sein Öffnen oder Schließen). Module verwalteter und regulärer Formen unterscheiden sich hauptsächlich darin, dass das Modul verwaltetes Formular Klar nach Kontext getrennt. Jede Prozedur oder Funktion muss eine Kompilierungsanweisung haben. Wenn die Kompilierungsanweisung nicht angegeben ist, wird diese Prozedur oder Funktion auf der Serverseite ausgeführt. In der üblichen Form wird der gesamte Code auf der Client-Seite ausgeführt.

Die verwaltete Formularstruktur enthält einen Variablendeklarationsabschnitt, Beschreibungen von Prozeduren und Funktionen und den Hauptteil des Programms (wird ausgeführt, wenn das Formular initialisiert wird). Wir können auf Standardformularereignisse über die Liste der erwarteten Prozeduren und Funktionen des Formulars zugreifen (Strg+Alt+P), oder über die Eigenschaftenpalette des Formulars selbst.

Wird dem Formular das Hauptattribut zugewiesen, so werden die Eigenschaften und Methoden des als Hauptattribut verwendeten Anwendungsobjekts im Formularmodul verfügbar.

Objektmodul

• kann alle 3 Bereiche enthalten
• serverseitig durchgeführt

Dieses Modul ist für die meisten Konfigurationsobjekte verfügbar und im Allgemeinen für die Verarbeitung von Ereignissen gedacht, die direkt mit dem Objekt zusammenhängen. Zum Beispiel Ereignisse zum Erfassen und Löschen von Objekten, Prüfen, ob die Details eines Objekts ausgefüllt sind, Veröffentlichen eines Dokuments usw.

Einige Objektmodulereignisse duplizieren Formularmodulereignisse. Beispielsweise Ereignisse im Zusammenhang mit dem Datensatz. Es versteht sich jedoch, dass die Ereignisse des Formularmoduls nur auf dem spezifischen Formular des Objekts ausgeführt werden, d. h. wenn das spezifische Formular geöffnet wird. Und die Ereignisse des Objektmoduls werden in jedem Fall aufgerufen, sogar zum Zeitpunkt der Programmarbeit mit dem Objekt. Wenn Sie also Methoden benötigen, die einem Objekt zugeordnet sind, ohne an eine bestimmte Form des Objekts gebunden zu sein, dann ist es besser, dafür das Objektmodul zu verwenden.

Objektmanager-Modul

• kann alle 3 Bereiche enthalten
• serverseitig durchgeführt

Das Objektmanager-Modul erschien erst ab Version 1C 8.2. Das Manager-Modul existiert für alle Anwendungsobjekte und dient dazu, dieses Objekt als Konfigurationsobjekt zu verwalten. Mit dem Manager-Modul können Sie die Funktionalität eines Objekts erweitern, indem Sie Prozeduren und Funktionen einführen (schreiben), die nicht für eine bestimmte Instanz des Datenbankobjekts gelten, sondern für das Konfigurationsobjekt selbst. Das Objektmanager-Modul ermöglicht es Ihnen, gemeinsame Prozeduren und Funktionen für ein bestimmtes Objekt zu platzieren und von außen darauf zuzugreifen, zum Beispiel von der Verarbeitung (natürlich, wenn diese Prozedur oder Funktion mit dem Export-Schlüsselwort versehen ist). Was bringt uns das Neues? Im Allgemeinen nichts anderes, als Prozeduren nach Objekten zu organisieren und sie an getrennten Orten zu speichern - Objekt-Manager-Module. Wir können diese Prozeduren und Funktionen genauso gut in gemeinsamen Modulen platzieren, aber 1C empfiehlt, gemeinsame Prozeduren und Funktionen von Objekten im Objektmanagermodul zu platzieren. Anwendungsbeispiele der Prozeduren und Funktionen des Moduls Objektmanager: erstmaliges Ausfüllen einzelner Angaben eines Verzeichnisses oder Dokuments unter bestimmten Bedingungen, Kontrolle des Ausfüllens von Angaben eines Verzeichnisses oder Dokuments unter bestimmten Bedingungen usw.

Befehlsmodul

• kann einen Abschnitt enthalten, der Prozeduren und Funktionen beschreibt
• Clientseitig ausgeführt

Befehle sind Objekten, die Anwendungsobjekten oder der Konfiguration insgesamt untergeordnet sind. Jeder Befehl hat ein Befehlsmodul, in dem Sie eine vordefinierte CommandProcess()-Prozedur zum Ausführen dieses Befehls beschreiben können.

Was sind Module und wofür sind sie genau gedacht? Das Modul enthält den Programmcode. Darüber hinaus ist anzumerken, dass im Gegensatz zur 7.7-Plattform, wo sich der Code sowohl in den Eigenschaften der Formularelemente als auch in den Zellen der Layouttabellen befinden konnte, auf der 8.x-Plattform jede Codezeile lokalisiert werden muss in irgendeinem Modul. Typischerweise besteht ein Modul aus drei Abschnitten – einem Abschnitt zur Beschreibung von Variablen, einem Abschnitt zur Beschreibung von Prozeduren und Funktionen und einem Abschnitt für das Hauptprogramm. Diese Struktur ist mit einigen Ausnahmen für fast alle Plattformmodule typisch. Einige Module haben keinen Variablendeklarationsabschnitt und keinen Hauptprogrammabschnitt. Zum Beispiel Sitzungsmodul und jedes allgemeine Modul.

Der Ausführungskontext von Modulen wird allgemein in Client- und Serverkontexte unterteilt. Außerdem können einige Module sowohl clientseitig als auch serverseitig kompiliert werden. Und einige sind rein serverseitig oder clientseitig. So:

Anwendungsmodul

Das Modul wurde entwickelt, um die Momente des Anwendungsstarts (Laden der Konfiguration) und deren Abschluss zu erfassen. Und in den entsprechenden Veranstaltungen können Sie die Überprüfungsverfahren veranlassen. Zum Beispiel zu Beginn der Anwendung eventuelle Konfigurationsreferenzdaten aktualisieren, am Ende der Arbeit fragen, ob es sich überhaupt lohnt, sie stehen zu lassen, vielleicht ist der Arbeitstag noch nicht zu Ende. Darüber hinaus fängt es Ereignisse von externen Geräten wie Handels- oder Steuergeräten ab. Es ist erwähnenswert, dass das Anwendungsmodul die beschriebenen Ereignisse nur im Fall eines interaktiven Starts abfängt. Diese. wenn das Programmfenster selbst erstellt wird. Dies geschieht nicht, wenn die Anwendung im COM-Verbindungsmodus gestartet wird.

Es gibt zwei verschiedene Anwendungsmodule in der 8.2-Plattform. Dies sind das Common Application-Modul und das Managed Application-Modul. Sie werden ausgelöst, wenn verschiedene Clients gestartet werden. So wird das verwaltete Anwendungsmodul ausgelöst, wenn der Webclient, Thin Client und Thick Client im verwalteten Anwendungsmodus gestartet werden. Und das reguläre Anwendungsmodul wird ausgelöst, wenn der Thick Client im normalen Anwendungsmodus gestartet wird.

Alle Abschnitte können im Anwendungsmodul platziert werden - Beschreibungen von Variablen, Prozeduren und Funktionen sowie Beschreibungen des Hauptprogramms. Das Anwendungsmodul wird auf der Client-Seite kompiliert, was uns in der Verfügbarkeit vieler Arten von Daten stark einschränkt. Sie können den Kontext eines Anwendungsmoduls mit den Methoden gemeinsam genutzter Module erweitern, für die die Call Server-Eigenschaft festgelegt ist. Alle als Export gekennzeichneten Variablen und Methoden sind in jedem clientseitigen Konfigurationsmodul verfügbar. So verlockend es auch sein mag, setzen Sie hier nicht zu viele Methoden ein. Je mehr Code es enthält, desto länger ist die Kompilierungszeit und folglich die Startzeit der Anwendung, was für Benutzer sehr ärgerlich ist.

Wie oben erwähnt, handhabt das Anwendungsmodul die Start- und Endereignisse der Anwendung. Um jedes dieser Ereignisse im Anwendungsmodul zu verarbeiten, gibt es ein paar Handler Before ... und When ... Der Unterschied zwischen ihnen besteht darin, dass die Aktion noch nicht ausgeführt wurde, wenn der Code im Handler Before ... ausgeführt wird stattgefunden hat und wir die Ausführung ablehnen können. Dafür gibt es die Ablehnungsoption. In den On-Handlern hat die Aktion bereits stattgefunden, und wir können uns nicht weigern, die Anwendung zu starten oder zu beenden.

Externes Anschlussmodul

Der Zweck des Moduls ist ähnlich dem Zweck des Anwendungsmoduls. Es behandelt die Start- und Endpunkte der Anwendung. Das externe Verbindungsmodul wird ausgelöst, wenn die Anwendung im Com-Verbindungsmodus gestartet wird. Der Outer-Join-Prozess selbst ist kein interaktiver Prozess. In diesem Modus erfolgt die programmgesteuerte Arbeit mit der Infobase und das Anwendungsfenster wird nicht geöffnet, was bestimmte Einschränkungen für die Verwendung von Methoden auferlegt, die für die interaktive Arbeit vorgesehen sind. In diesem Modus können Sie keine Dialogformularaufrufe, Warnmeldungen usw. verwenden. Sie werden einfach nicht funktionieren.

Wie im Anwendungsmodul stehen hier Abschnitte zur Beschreibung von Variablen, Methoden und ein Abschnitt für das Hauptprogramm zur Verfügung. Sie können auch Exportvariablen und -methoden deklarieren. Der Unterschied besteht darin, dass im com-Verbindungsmodus alle Arbeiten mit der Infobase auf der Serverseite stattfinden, sodass das externe Verbindungsmodul ausschließlich auf dem Server kompiliert wird. Dementsprechend sind Exportvariablen und Methoden gängiger Client-Module darin nicht verfügbar.

Sitzungsmodul

Dies ist ein hochspezialisiertes Modul und dient ausschließlich der Initialisierung von Sitzungsparametern. Warum mussten Sie dafür ein eigenes Modul erstellen? Dies liegt an der Tatsache, dass der Initialisierungsprozess möglicherweise die Ausführung von Code erfordert und außerdem die Anwendung unter verschiedenen Clients gestartet werden kann (was zur Ausführung verschiedener Anwendungsmodule oder externer Verbindungsmodule führt) und Sitzungsparameter müssen in jedem Startmodus initialisiert werden. Daher wurde ein zusätzliches Modul benötigt, das in jedem Anwendungsstartmodus ausgeführt wird.

Es gibt ein einzelnes "SetSessionParameters"-Ereignis im Sitzungsmodul, das als erstes ausgelöst wird, sogar vor dem BeforeSystemStart-Ereignis des Anwendungsmoduls. Es hat keinen Variablendeklarationsabschnitt und keinen Hauptprogrammabschnitt. Und es ist auch unmöglich, Exportmethoden zu deklarieren. Das Modul wird serverseitig kompiliert.

Vermeiden Sie die Versuchung, dass dieses Modul jedes Mal ausgeführt wird, wenn die Anwendung gestartet wird, und platzieren Sie darin Code, der nicht direkt mit der Initialisierung von Sitzungsparametern zusammenhängt. Dies liegt daran, dass der SetSessionParameters-Handler während des Systembetriebs wiederholt aufgerufen werden kann. Dies geschieht beispielsweise, wenn wir auf nicht initialisierte Parameter zugreifen. Und obwohl es möglich ist, den Moment des ersten Starts dieses Ereignisses zu erfassen (RequiredParameters hat den Typ Undefined), sollte jedoch beachtet werden, dass dieses Modul im privilegierten Modus kompiliert wird, d.h. Zugriffsrechte werden nicht kontrolliert. Und der zweite Punkt: Wir können immer noch nicht hundertprozentig sicher sein, dass das System eingeführt wird. Plötzlich schlägt das Anwendungsmodul fehl und wir versuchen, eine Aktion mit der Datenbank auszuführen.

Allgemeine Module

Die Module sollen einige allgemeine Algorithmen beschreiben, die von anderen Konfigurationsmodulen aufgerufen werden. Das allgemeine Modul enthält keinen Variablendeklarationsabschnitt und keinen Hauptprogrammabschnitt. Sie können darin Exportmethoden deklarieren, deren Barrierefreiheitskontext durch Kompilierungsflags bestimmt wird. Da der Variablendeklarationsabschnitt nicht verfügbar ist, ist es nicht möglich, globale Variablen in gemeinsam genutzten Modulen zu definieren. Dazu müssen Sie die Funktionen gängiger Module mit Rückgabewert-Caching oder ein Applikationsmodul nutzen. Es sollte beachtet werden, dass selbst wenn die Wiederverwendungseigenschaft des gemeinsamen Moduls auf "Für die Dauer der Sitzung" eingestellt ist, die Lebensdauer der zwischengespeicherten Werte in diesem Fall 20 Minuten ab dem Zeitpunkt, an dem sie gespeichert wurden, nicht überschreitet Zuletzt aufgerufen.
Das Verhalten des gemeinsam genutzten Moduls hängt von den eingestellten Parametern ab (global oder nicht, verschiedene Kompilierungsflags, ob ein Serveraufruf verfügbar ist usw.). In diesem Artikel werden wir nicht alle Arten von Einstellungen sowie Verhaltensmerkmale und Fallstricke berücksichtigen, die auftreten, wenn Eigenschaftsflags unangemessen gesetzt werden. Dies ist ein Thema für einen separaten Artikel. Lassen Sie uns auf einige Punkte eingehen, die beim Setzen von Flags beachtet werden sollten:

• Es ist eine gute Faustregel, das "Global"-Flag nicht überall zu verwenden. Dies verkürzt die Startzeit der Anwendung und verbessert die Lesbarkeit des Codes (natürlich, wenn das gemeinsame Modul einen vollständig aussagekräftigen Namen hat).
• Es ist nicht ratsam, mehr als ein Übersetzungskennzeichen zu verwenden. Es gibt nicht so viele Methoden, die in unterschiedlichen Kontexten durchgeführt werden müssen, und wenn solche Methoden dennoch erforderlich sind, dann kann ihnen ein separates gemeinsames Modul zugeordnet werden.
• Das Flag „Call Server“ ist nur sinnvoll, wenn das Modul „Auf dem Server“ kompiliert wird. Daher sollten alle anderen Kompilierungsflags entfernt werden, um verschiedene Probleme zu vermeiden.
• Wenn die Modulmethoden für die Massendatenverarbeitung, das Lesen und Schreiben in die Datenbank verwendet werden, ist es zur Erhöhung der Arbeitsgeschwindigkeit besser, die Zugriffskontrolle durch Setzen des Flags "Privileged" zu deaktivieren. Dieser Modus ist nur für gemeinsam genutzte Module verfügbar, die auf dem Server kompiliert wurden.

Formularmodul

Es soll Benutzeraktionen verarbeiten, d.h. verschiedene Ereignisse im Zusammenhang mit der Dateneingabe und Verarbeitung der Richtigkeit ihrer Eingabe. Modul regelmäßige Form vollständig auf dem Client kompiliert. Ein verwaltetes Formularmodul hingegen ist klar durch den Ausführungskontext abgegrenzt, sodass alle Variablen und Methoden eine Kompilierungsdirektive haben müssen. Wenn die Direktive nicht explizit angegeben ist, wird diese Variable oder Methode serverseitig kompiliert. Im Formularmodul stehen Abschnitte zur Beschreibung von Variablen und Methoden sowie ein Abschnitt für das Hauptprogramm zur Verfügung.

Objektmodul

Dieses Modul ist typisch für viele Konfigurationsobjekte und im Allgemeinen für die Verarbeitung von Objektereignissen gedacht. Zum Beispiel die Ereignisse des Schreibens und Löschens von Objekten, das Ereignis des Buchens von Dokumenten usw.

Einige Objektmodulereignisse duplizieren Formularmodulereignisse. Beispielsweise Ereignisse im Zusammenhang mit dem Datensatz. Es versteht sich jedoch, dass die Ereignisse des Formularmoduls nur auf einem bestimmten Formularobjekt ausgeführt werden. Im Allgemeinen kann es mehrere dieser Formen geben. Und die Ereignisse des Objektmoduls werden in jedem Fall aufgerufen, sogar zum Zeitpunkt der Programmarbeit mit dem Objekt. Wenn es daher notwendig ist, in allen Fällen Code auszuführen, dann ist es besser, dafür ein Objektmodulereignis zu verwenden.

Das Objektmodul wird ausschließlich auf dem Server kompiliert. Darin können Sie Exportvariablen und -methoden definieren, die in anderen Konfigurationsmodulen verfügbar sein werden. Mit Hilfe dieser Eigenschaften und Methoden können wir die Funktionalität des Objekts erheblich erweitern.

Objektmanager-Modul

Dieses Modul existiert für viele Konfigurationsobjekte. Der Hauptzweck dieses Moduls besteht darin, das Standardauswahlereignis, das zum Zeitpunkt der zeilenweisen Eingabe auftritt, neu zu definieren und die Funktionalität des Managers zu erweitern. Das Modul wird serverseitig kompiliert. Es ist möglich, Exporteigenschaften und -methoden zu definieren. Der Aufruf der Exportmethoden des Managers erfordert nicht die Erstellung des Objekts selbst.

Zu all dem oben Gesagten können Sie ein Bild einiger Konfigurationsmodule und Methoden zum gegenseitigen Aufrufen von Methoden im verwalteten Anwendungsmodus hinzufügen. Der Pfeil zeigt die Richtung an, in die Sie gehen können, um die entsprechende Methode aufzurufen. Wie aus dem Diagramm ersichtlich ist, ist der Serverkontext vollständig geschlossen. Aber vom Clientkontext aus ist es möglich, auf Servermethoden zuzugreifen.

Symbole auf dem Schema: O.M. Client - gemeinsames Client-Modul; OM Server - gemeinsames Servermodul; M.F. Client - Client-Prozeduren des Formularmoduls; M.F. Server - Serverprozeduren des Formularmoduls.