Grundlegende Details des Formulars. Verwaltete Formulardetails (1Cv8) Mit 1c verwalteten Formularen werden Details programmgesteuert hinzugefügt

Formulardetails

Eine Reihe von Formulardetails beschreibt die Zusammensetzung der Daten, die im Formular angezeigt, bearbeitet oder gespeichert werden. Gleichzeitig bieten die Formulardetails selbst keine Möglichkeit, Daten anzuzeigen und zu bearbeiten. Mit Formulardetails verknüpfte Formularelemente (siehe Abschnitt „Formularelemente“ in diesem Kapitel) werden zur Anzeige und Bearbeitung verwendet. Die Menge aller Formulardetails wird als Formulardaten bezeichnet.

Wichtig! Es ist zu beachten, dass im Gegensatz zu regulären Formularen alle Daten in einem verwalteten Formular in Form von Details beschrieben werden müssen. Es ist nicht erlaubt, Formularmodulvariablen als Datenquellen für Formularelemente zu verwenden.

Eine Zuordnung ist möglich Grundlegende Formulardetails, also Attribute, die die Standardfunktionalität des Formulars bestimmen (Formularerweiterung). Es ist zu beachten, dass ein Formular nur ein Hauptattribut haben kann.

Formularerweiterung– Dies sind zusätzliche Eigenschaften, Methoden und Formularparameter des ManagedForm-Objekts, die für das Objekt charakteristisch sind, das das Hauptelement des Formulars ist.

Während des Formularentwicklungsprozesses können Sie mithilfe der Eigenschaften „Anzeigen“ und „Bearbeiten“ explizit die Möglichkeit zum Anzeigen und Bearbeiten bestimmter Formulardetails in Bezug auf Rollen festlegen (weitere Einzelheiten finden Sie im Abschnitt „Rollenbasierte Formulareinstellungen“ der Anleitung „Editoren“) " Kapitel). Darüber hinaus kann die Verfügbarkeit eines bestimmten Attributs im Formular selbst über Funktionsoptionen konfiguriert werden (weitere Details zu Funktionsoptionen finden Sie im Kapitel „Konfigurationsschnittstellenverwaltung“).

Formularattributeigenschaft Gespeicherte Daten ist ein Zeichen dafür, dass eine interaktive Änderung der Details zu einem Versuch führt, die Formulardaten für die Bearbeitung zu sperren, sowie zum automatischen Setzen des Formularänderungsflags.

Datentypen, die in verwalteter Form verfügbar sind

Ein verwaltetes Formular unterscheidet sich von einem regulären Formular auch durch die Datentypen, mit denen es arbeitet. Wenn die Normalform mit den meisten von 1C:Enterprise bereitgestellten Typen funktioniert (einschließlich der Typen DirectoryObject, DocumentObject usw.), dann können in der verwalteten Form die folgenden Kategorien von Typen unterschieden werden:

  • Typen, die direkt im Formular verwendet werden, sind die Typen, die auf der Seite des Thin- und Web-Clients vorhanden sind (z. B. Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
  • Typen, die in spezielle Datentypen konvertiert werden – verwaltete Formulardatentypen. Solche Typen werden in der Liste der Formulardetails in Klammern angezeigt, zum Beispiel (DirectoryObject.Products);
  • dynamische Liste (weitere Einzelheiten finden Sie im Abschnitt „Dynamische Liste“ dieses Kapitels).

Konvertieren von Anwendungsobjekten in Formulardaten

Einige Anwendungstypen (z. B. DirectoryObject usw.) sind auf der Thin- und Web-Client-Seite nicht vorhanden (weitere Einzelheiten finden Sie im Kapitel „Konzept verwalteter Anwendungen“). Um solche Anwendungstypen im Formular darzustellen, hat die Plattform daher spezielle Datentypen eingeführt, die für die Arbeit in verwalteten Formularen konzipiert sind. Diese Funktion einer verwalteten Anwendung macht es erforderlich, Anwendungsobjekte in Formulardaten zu konvertieren (und umgekehrt).

Folgende Datentypen werden verwendet:

  • Formulardatenstruktur – enthält eine Reihe von Eigenschaften eines beliebigen Typs. Eigenschaften können andere Strukturen, Sammlungen oder Strukturen mit Sammlungen sein. Dieser Typ wird beispielsweise in der Form DirectoryObject dargestellt.
  • Eine FormDataCollection ist eine Liste typisierter Werte, ähnlich einem Array. Auf ein Sammlungselement wird über einen Index oder einen Bezeichner zugegriffen. In manchen Fällen ist der Zugang per Ausweis möglicherweise nicht möglich. Dies liegt an der Art des Anwendungsobjekts, das durch diese Sammlung dargestellt wird. Der Bezeichner kann eine beliebige Ganzzahl sein. Dieser Typ wird beispielsweise in Form eines tabellarischen Teils dargestellt.
  • Form DataStructureWithCollection ist ein Objekt, das gleichzeitig als Struktur und Sammlung dargestellt wird. Es kann wie jede dieser Entitäten behandelt werden. Dieser Typ stellt beispielsweise eine Reihe von Datensätzen in einem Formular dar.
  • Form DataTree – ein Objekt zum Speichern hierarchischer Daten.

Ein Anwendungsobjekt wird durch ein oder mehrere Formulardatenelemente dargestellt. Im Allgemeinen hängen Hierarchie und Zusammensetzung von Formulardaten von der Komplexität und Vernetzung der Anwendungsobjekte des verwalteten Formulars ab.

Beispielsweise wird ein Dokument, das einen tabellarischen Teil enthält, durch ein Objekt vom Typ FormDataStructure (das Dokument selbst) dargestellt, dem ein Objekt vom Typ FormDataCollection (tabellarischer Teil des Dokuments) untergeordnet ist.

Wichtig! Bei der Entwicklung einer Konfiguration ist zu beachten, dass Anwendungsobjekte nur auf dem Server verfügbar sind, während Formulardatenobjekte sowohl auf dem Server als auch auf dem Client verwendet werden können.

Übergeben von Daten zwischen den Client- und Serverteilen eines verwalteten Formulars

Tatsächlich können wir sagen, dass Formulardaten eine einheitliche Darstellung von Daten aus verschiedenen Anwendungsobjekten sind, mit denen das Formular einheitlich arbeitet und die sowohl auf dem Server als auch auf dem Client vorhanden sind. Das heißt, das Formular enthält eine „Projektion“ von Anwendungsobjektdaten in Form seiner eigenen Datentypen und führt bei Bedarf eine Konvertierung zwischen ihnen durch. Wenn der Konfigurationsentwickler jedoch seinen eigenen Datenverarbeitungsalgorithmus implementiert, muss er die Datenkonvertierung (von spezialisierten Typen in Anwendungstypen und umgekehrt) unabhängig durchführen.

Beim Bearbeiten von Formulardetails in einem speziellen Editor (weitere Informationen finden Sie im Abschnitt „Formulardetails“ des Kapitels „Editoren“) besteht die Möglichkeit, die Datenübertragung zwischen Client und Server während der Ausführung des Formulars zu beeinflussen. Hierzu wird die Spalte des Detaileditors verwendet. Verwenden Sie immer. Die Wirkung dieser Eigenschaft unterscheidet sich für drei Arten von Attributen:

  • Für ein einer dynamischen Liste untergeordnetes Attribut (dynamische Listenspalte):
    • Eigenschaft aktiviert – das Attribut wird immer aus der Datenbank gelesen und in die Formulardaten aufgenommen;
    • Die Eigenschaft ist deaktiviert – das Attribut wird nur dann aus der Datenbank gelesen und in die Formulardaten aufgenommen, wenn dem Attribut oder seinem untergeordneten Attribut ein aktuell sichtbares Formularelement zugeordnet ist.
  • Für Requisiten, die der Bewegungssammlung untergeordnet sind:
    • Eigenschaft ist aktiviert – Dokumentbewegungen werden aus der Datenbank gelesen und sind in den Formulardaten vorhanden;
    • -Eigenschaft ist deaktiviert – Dokumentbewegungen werden nicht aus der Datenbank gelesen und nicht in die Formulardaten aufgenommen (sofern kein Formularelement vorhanden ist, das auf Dokumentbewegungen verweist).
  • Weitere Formulardetails:
    • Eigenschaft ist aktiviert – das Attribut ist in den Formulardaten vorhanden, unabhängig davon, ob mindestens ein Formularelement vorhanden ist, das mit dem Attribut oder seinem untergeordneten Attribut verknüpft ist;
    • Die Eigenschaft ist deaktiviert – das Attribut ist nur dann in den Formulardaten vorhanden, wenn dem Attribut oder seinem untergeordneten Attribut ein Formularelement zugeordnet ist. Im Gegensatz zu dynamischen Listenattributen spielt hier die Sichtbarkeit des mit dem Attribut verknüpften Elements keine Rolle.

Notiz. Es ist zu beachten, dass sich die für das übergeordnete Attribut festgelegte Eigenschaft auf alle untergeordneten Attribute auswirkt. Wenn beispielsweise die Eigenschaft „Verwenden“ für den tabellarischen Teil des Dokuments immer deaktiviert ist, geht das System davon aus, dass diese Eigenschaft auch für alle untergeordneten Details deaktiviert ist (ungeachtet des tatsächlichen Status der Eigenschaft).

Methoden zum Konvertieren von Anwendungsobjektdaten in Formulardaten

Um Anwendungsobjekte in Formulardaten und zurück zu konvertieren, gibt es eine Reihe globaler Methoden:

  • ValueInFormData(),
  • FormDataInValue(),
  • CopyFormData().

Wichtig! Methoden, die mit Anwendungsobjekten arbeiten, sind nur in Serverprozeduren verfügbar. Die Methode zum Kopieren von Werten zwischen Formulardaten ist auf dem Server und auf dem Client verfügbar, da sie keine Anwendungsobjekte als Parameter benötigt.

Beim Konvertieren von Formulardaten in ein Anwendungsobjekt müssen Sie deren Kompatibilität berücksichtigen.

  • ValueInFormData() – wandelt ein Anwendungstypobjekt in Formulardaten um;
  • FormDataInValue() – wandelt Formulardaten in ein Anwendungstypobjekt um;
  • CopyFormData() – kopiert Formulardaten, die eine kompatible Struktur haben. Gibt True zurück, wenn der Kopiervorgang erfolgreich war, oder False, wenn die Objektstruktur inkompatibel ist.

Notiz. Beim Ausführen von Standardaktionen (Öffnen eines Formulars, Ausführen eines Standard-Schreibbefehls usw.) eines Formulars mit den Hauptdetails wird die Konvertierung automatisch durchgeführt.

Lassen Sie uns ein Beispiel dafür geben, wie Sie die Datentransformation in Ihren eigenen Algorithmen verwenden.

&OnServerProcedure When CreateOnServer(Failure, StandardProcessing)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

Ende des Verfahrens

&OnClient-Prozedur Write()

WriteOnServer();

Ende des Verfahrens

&OnServer-Prozedur WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Ende des Verfahrens

Das ManagedForm-Objekt verfügt auch über Methoden, die auf dem Server verfügbar sind:

  • ValueFormAttribute() – konvertiert ein Anwendungstypobjekt in das angegebene Formularattribut.
  • FormAttributeVValue() – konvertiert ein Formulardatenattribut in ein Objekt eines Anwendungstyps.

Die Verwendung dieser Methoden ist in der Regel komfortabler, da sie beispielsweise Informationen über die Art der Formulardetails enthalten. Darüber hinaus legt die Methode Form AttributesValue() die Korrespondenz zwischen den Formulardaten und dem Objekt fest, die beim Generieren von Nachrichten verwendet wird. Mehr dazu erfahren Sie im Kapitel „Funktionen der Service-Navigation“.

Lassen Sie uns ein Beispiel für die Verwendung dieser Methoden geben.

&OnServer-Prozedur RecalculateOnServer()

// Konvertiert das Object-Attribut in ein Anwendungsobjekt. Document = Form AttributesValue("Object"); // Führt eine Neuberechnung mit der im Dokumentmodul definierten Methode durch. Document.Recalculate(); // Konvertiert das Anwendungsobjekt zurück in eine Requisite. ValueFormAttributes(Document, „Object“);

Ende des Verfahrens

Softwareschnittstelle

FormDataTree

  • FindById
  • GetItems

Beschreibung:

Entwickelt, um einen Baum in verwalteten Formulardaten zu modellieren.

Dieses Objekt kann zu/von XDTO serialisiert werden. Der diesem Objekt entsprechende XDTO-Typ ist im Namespace definiert. Name des XDTO-Typs:

GetItems

Syntax:

GetItems()

Rückgabewert:

Typ: Formulardatensammlung von Baumelementen.

Beschreibung:

Ruft eine Sammlung von Baumelementen der obersten Ebene ab.

Verfügbarkeit: Client, Server, Thin Client, Webclient.

FindById

Syntax:

FindById(<Идентификатор>)

Optionen:

<Идентификатор>(erforderlich)

Nummer eingeben. Bezeichner des Baumelements.

Rückgabewert:

Typ:FormDataTreeElement.

Beschreibung:

Ruft ein Sammlungselement nach ID ab.

Verfügbarkeit: Client, Server, Thin Client, Webclient.

FormDataTreeItem

Eigenschaften:

<Имя свойства> (<Имя свойства>)

  • GetId (GetId)
  • GetParent
  • GetItems
  • Eigentum

Beschreibung:

Formulardatenbaumelement.

FormDataTreeItemCollection

Sammlungselemente: DataFormTreeElement

Für ein Objekt ist es möglich, die Sammlung mit dem Operator For every... From... Loop zu durchlaufen. Der Durchlauf wählt die Elemente der Sammlung aus. Der Zugriff auf ein Sammlungselement ist über den [...]-Operator möglich. Als Argument wird der Index des Elements übergeben.

  • Einfügen
  • Hinzufügen
  • Index (IndexOf)
  • Zählen
  • Klar
  • Erhalten
  • Bewegen
  • Löschen

Beschreibung:

Sammlung von Holzelementen.

Verfügbarkeit: Client, Server, Thin Client, Webclient.

Siehe auch:

  • FormDataTreeElement, GetElements-Methode
  • DataFormTree, Methode GetItems

Merkmale der Arbeit mit einem Wertebaum

Baumaktualisierung

Es gibt ein Problem Stürze Plattformen beim Aktualisieren des Baums.

Wenn ein Knoten im Baum erweitert und ein untergeordneter Knoten ausgewählt wurde, dann beim Aktualisieren des Baums mit der Funktion ValueInFormData die Plattform fällt.

Lösung: Sie müssen den Baum vor der Aktualisierung löschen.

Zum Beispiel:

&Auf dem Server Prozedur ClearTree(elements) Für jedes Element aus elements Schleife ClearTree(element.GetElements()); EndCycle; elements.Clear(); Ende des Verfahrens

&Auf der Serverprozedur Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Ende des Verfahrens

&OnClient Procedure OnDateOnChange(Element) Fill ConceptTree(); Ende des Verfahrens

Mit der 1C:Enterprise-Plattform können Sie Elemente eines verwalteten Formulars programmgesteuert hinzufügen und ändern. Lassen Sie uns herausfinden, warum dies erforderlich sein könnte.

In mehreren Fällen kann eine Software-Änderung des Formulars erforderlich sein:

  • Bei der Finalisierung von Standardkonfigurationen, um den anschließenden Update-Vorgang zu erleichtern. In diesem Fall wird nur das Formularmodul geändert. Module sind viel einfacher zu aktualisieren als Formulare.
  • Bei der Implementierung einiger gängiger Algorithmen. Beispielsweise kann im Subsystem „Verbot der Bearbeitung von Objektdetails“ programmgesteuert eine Schaltfläche für alle mit dem Subsystem verbundenen Objekte erstellt werden, um die Möglichkeit zur Bearbeitung von Details zu ermöglichen.
  • Bei der Implementierung einiger spezifischer Algorithmen. Beispielsweise werden im Nomenklaturverzeichnis Felder zum Bearbeiten zusätzlicher Details erstellt.

In einem verwalteten Formular können Sie Folgendes programmgesteuert hinzufügen, ändern und löschen:

  • Requisiten;
  • lokale Teams;
  • Elemente.

Alle diese Vorgänge sind nur auf dem Server möglich.

Programmatische Umgestaltung weist Einschränkungen auf:

  • Sie können nur programmgesteuert hinzugefügte Details/Befehle/Elemente löschen. Sie können im Konfigurator erstellte Objekte nicht programmgesteuert löschen.
  • Sie können kein Attribut als Hauptattribut zuweisen.

Formularbefehle ändern

Um die Zusammensetzung von Befehlen für ein Objekt zu verwalten VerwalteteForm Es gibt eine Sammlung Mannschaften

    Hinzufügen (< ИмяКоманды >)

    Menge ()

    Finden (< ИмяКоманды >)

    Löschen (< Команда >)

Die Teams-Sammlung ist sowohl auf dem Client als auch auf dem Server verfügbar. Sie können die Sammlung (Methoden „Add()“ und „Delete()“) nur auf dem Server ändern. Sie können sowohl auf dem Client als auch auf dem Server nach Elementen suchen und deren Anzahl abrufen (die Methoden „Find()“ und „Count()“).

Als Beispiel für die Arbeit mit Formularbefehlen erstellen wir einen neuen ChangeHistory-Befehl mit der Überschrift „ChangeHistory...“, der den Handler aufruft Anzeigeverlauf(). Die Erstellung erfolgt beim Öffnen des Formulars.

&Auf dem Server
Verfahren WhenCreatingOnServer(Failure, StandardProcessing)
Team = Teams. Hinzufügen( „Geschichte der Veränderungen“);
Team . Aktion = ;
Team . Titel = „Geschichte der Veränderungen…“;
Ende des Verfahrens
&OnClient
Verfahren Connectable_DisplayHistory(Befehl)
// Befehlsaktionen
Ende des Verfahrens

Der Befehlshandler muss sich in einem Formular befinden und über eine &OnClient-Kompilierungsanweisung verfügen.

Formulardetails ändern

Das Lesen der Zusammensetzung der Formulardetails wird von der Funktion durchgeführt Beschaffe die Einzelheiten(< Путь >) gibt ein Array vom Typ FormAttributes zurück. Der Funktionsparameter gibt den Pfad zum übergeordneten Attribut (als String) an. Wenn der Parameter weggelassen oder eine leere Zeichenfolge angegeben wird, werden die Details der obersten Ebene zurückgegeben.

Das Ändern der Details erfolgt mit der Methode Details ändern(<Details hinzugefügt>, <Abnehmbare Details>) Objekt VerwalteteForm. Zu Parametern Details hinzugefügt Und Abnehmbare Details Es werden Arrays mit Elementen vom Typ Form Attributes übertragen.

Aufmerksamkeit!

Der Prozess der Änderung der Zusammensetzung von Details ist recht ressourcenintensiv. Das Formular wird tatsächlich neu erstellt. Dabei erfolgt die Arbeit mit Formulardetails im Batch-Modus.

Erstellen wir ein neues Formularattribut mit dem Namen Käufer:


AddedDetails = Neues Array;
Details hinzugefügt. Hinzufügen(Neue Formularattribute(„Käufer“, neue Typbeschreibung („DirectoryLink. Gegenparteien“), „Kunde“));

// Änderungen in der Zusammensetzung der Details
);

Formularelemente ändern

Um die Zusammensetzung von Elementen eines Objekts zu steuern VerwalteteForm Es gibt eine Sammlung Elemente. Die Sammlung verfügt über mehrere Methoden:

    Einfügen (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

    Hinzufügen (< Имя>, < ТипЭлемента>, < Родитель >)

    Menge ()

    Finden (< Имя >)

    Bewegen(< Элемент>, < Родитель>, < МестоРасположения >)

    Löschen (< Элемент >)

Die Items-Sammlung ist sowohl auf dem Client als auch auf dem Server verfügbar. Eine Sammlung ändern (Methoden einfügen). () , Add (), Move () und Delete () sind nur auf dem Server verfügbar. Sie können sowohl auf dem Client als auch auf dem Server nach Elementen suchen und deren Anzahl abrufen (die Methoden „Find()“ und „Count()“). Sammlungselemente können sein:

  • Gruppe formen;
  • FormTable;
  • Formularfeld;
  • Schaltfläche „Formular“.

Sie können Formularelementen programmgesteuert Ereignishandler zuweisen. Für diese Zwecke ist die Methode vorgesehen SetAction(< ИмяСобытия>, < Действие >) .

Schauen wir uns einige der häufigsten Beispiele für die Arbeit mit Befehlen, Details und Formularelementen an.

Einen Befehl und die zugehörige Schaltfläche hinzufügen:

// Einen Befehl erstellen
Team = Teams. Hinzufügen( „Geschichte der Veränderungen“);
Team . Aktion = „Plug-in_DisplayHistory“; // Das Formular muss eine Prozedur mit dem angegebenen Namen enthalten
Team . Überschrift = „Geschichte der Veränderungen…“;
// Eine Schaltfläche erstellen und sie einem Befehl zuordnen
Element = Artikel. Hinzufügen( „Geschichte der Veränderungen“, Type("FormButton" ));
Element.Befehlsname = „Geschichte der Veränderungen“;

Hinzufügen eines Attributs und des zugehörigen Eingabefelds:

// Beschreibung der hinzugefügten Details
AddedDetails = Neues Array;
Details hinzugefügt. Hinzufügen(Neue Formular-Requisiten („Käufer“, neue Typbeschreibung ( „DirectoryLink. Gegenparteien“), "Klient" ));
// Ändern der Zusammensetzung von Details
ChangeDetails(Details hinzugefügt);
// Eingabefeld erstellen und mit dem Attribut verbinden
Element = Artikel. Add("Buyer" , Type("FormField" ));
Element . Ansicht = FormFieldView. Eingabefeld;
Element . PathToData= "Käufer" ;

Zuweisen eines Event-Handlers zu einem Formularelement:

ArtikelKunde. SetAction(„Wenn es sich ändert“, „Connected_BuyerOnChange“);

&OnClient
Verfahren Connected_BuyerOnChange(Element)
// Ereignisaktionen
Ende des Verfahrens

Aufmerksamkeit!

Prozeduren, die mithilfe der Methode aus dem Code als Ereignishandler festgelegt werden SetAction(), wird empfohlen, das Präfix Connectable_ zu setzen.

Aufmerksamkeit!

Sie können die Verarbeitung mit Beispielen für die programmatische Suche und Änderung von Details, Befehlen und Elementen eines verwalteten Formulars herunterladen.

Die Formularangaben stellen die Verbindung mit den Daten sicher. In diesem Fall kann eines (und nur eines) der Details als das Hauptdetail bezeichnet werden; Es muss nicht unbedingt der Datentyp sein, auf den wir das Formular zeichnen. Das Verhalten des Formulars hängt jedoch vom Datentyp des Hauptattributs ab. Neben der Änderung des Verhaltens des Formulars ändert sich auch der Kontext des Formularmoduls. Zusammen mit den Methoden und Eigenschaften des Formulars werden darin auch die Methoden und Eigenschaften des Objekts verfügbar, bei dem es sich um den Wert des Hauptattributs handelt. Es ist wichtig, dass Formulare vom Typ Freiform keine grundlegenden Details enthalten. In diesem Fall wird das Verhalten des Formulars nur durch die Einstellungen des Benutzers bestimmt. Betrachten wir Fragen zu den grundlegenden Details.

Frage 10.05 der Prüfung 1C: Platform Professional. Wofür wird das Hauptformularattribut verwendet?

  1. Definiert die Datenquelle für das Formular als Ganzes
  2. Definiert die Standardfunktionen der Plattform für die Arbeit mit dem Formular mit Daten des im Hauptattribut angegebenen Typs
  3. Bereitstellung der Möglichkeit, programmgesteuert auf Objektdetails aus dem lokalen Formularkontext zuzugreifen
  4. Bietet Visualisierung von Objektdetails im Formulardialog
  5. 2 und 3 sind richtig
  6. 1 und 2 sind richtig

Die richtige Antwort ist Nummer sechs, siehe oben.


Frage 10.06 der Prüfung 1C: Platform Professional. Wozu werden die Formularangaben benötigt?
  1. Beschreibt den Inhalt der Daten, die in einem Formular angezeigt, bearbeitet oder gespeichert werden
  2. Zum Anzeigen und Bearbeiten von Daten in einem Formular
  3. 1 und 2 sind richtig

Die richtige Antwort ist die dritte – beides.

Frage 10.07 der Prüfung 1C: Platform Professional. Um einer beliebigen kontrollierten Form grundlegende Attribute zuzuweisen ...

  1. Sie müssen in den Eigenschaften der Formularattribute das Kontrollkästchen „Grundlegende Angaben“ aktivieren
  2. Sie müssen die Eigenschaft „Daten“ des Formulars ausfüllen, indem Sie das erforderliche Formularattribut auswählen

Die richtige Antwort ist die zweite:

Frage 10.08 der Prüfung 1C: Platform Professional. Um die Hauptdetails einer beliebigen regulären Form zuzuordnen...
  1. Das Formular muss zum Hauptformular gemacht werden, die Hauptdetails werden automatisch ermittelt
  2. Sie müssen in den Eigenschaften der Formularattribute das Kontrollkästchen „Grundlegende Angaben“ aktivieren
  3. Sie müssen zum Menü „Bearbeiten“, „Grundlegende Details“ gehen und den gewünschten Wert auswählen
  4. Sie müssen die Eigenschaft „Daten“ des Formulars ausfüllen, indem Sie das erforderliche Formularattribut auswählen

Die vierte richtige Antwort lautet:

Die wichtigsten Details sind fett hervorgehoben:

Frage 10.09 der Prüfung 1C: Platform Professional. Wenn es ein Hauptformularattribut gibt, ist es dann möglich, ein weiteres Hauptattribut hinzuzufügen?
  1. Es ist unmöglich
  2. Dies ist möglich, indem der Formularattributeigenschaft der entsprechende Wert zugewiesen wird
  3. Dies ist nur programmgesteuert möglich, wenn auf das Objekt „Form“ zugegriffen wird
  4. Dies ist möglich, indem der entsprechenden Formulareigenschaft ein weiterer Wert hinzugefügt wird

Die richtige Antwort ist die erste, es gibt unbedingt eine Hauptvoraussetzung, denn Der Zusammenhang mit dem Objekt muss eindeutig sein.

Frage 10.113 der Prüfung 1C: Platform Professional. Welches der in der Abbildung dargestellten Details des Formulars ist das wichtigste?

  1. Liste der Währungskurse
  2. DirectoryObject
  3. Verzeichnisformulare enthalten keine grundlegenden Details
  4. Verzeichnisformulare enthalten alle grundlegenden Details
Die zweite richtige Antwort ist die fett gedruckte.

Die Steuerung des Formulars erfolgt über verschiedene Formularelemente, die hierarchisch auf der Registerkarte angeordnet sind Elemente Formulardesigner. Das wichtigste Element ist das Formular selbst, das sich an der Spitze der Elementhierarchie befindet und dem die übrigen Elemente untergeordnet sind.

Alle Formularelemente können in fünf Gruppen unterteilt werden: Felder, Gruppierungselemente, Schaltflächen, Dekorationen und Tabellen. In meinen Artikeln werde ich jede der Gruppen analysieren. In diesem Artikel beginnen wir mit der Untersuchung einer der Arten von Feldelementen – Eingabefeld, aber vorher lernen wir, wie man dem Formular ein Element hinzufügt.

Elemente zu einem Formular hinzufügen

Das geht ganz einfach: Sie müssen das Element auswählen Bilden im Fenster „Form Design Elements“ und klicken Sie auf die Schaltfläche „Hinzufügen“. Anschließend öffnet sich ein Fenster, in dem Sie den gewünschten Elementtyp auswählen müssen

Nach der Auswahl erscheint das gewünschte Element im Fenster Elemente.

Verwaltetes Formularelement Feld

Schauen wir uns ein verwaltetes Formularelement an Feld. Dieses Element wird benötigt, um Informationen in das Formular einzugeben. Und auch um beliebige Informationen anzuzeigen. Nachdem Sie dieses Element zum Formular hinzugefügt haben, wird rechts die Eigenschaftenpalette des Formularelements geöffnet. Im Moment dürften Sie an zwei Eigenschaften interessiert sein – DataPath und View.

In der DataPath-Eigenschaft kann der Entwickler ein Formularelement mit dem gewünschten Formularattribut verknüpfen. Bitte beachten Sie, dass nach dem Hinzufügen des Elements Eingabefeld Auf dem Formular wurde es nicht auf dem Formular selbst angezeigt. Dies geschah, weil unser neues Element nicht mit verknüpft ist. Ich habe beispielsweise auf dem Verarbeitungsformular mehrere Attribute mit unterschiedlichen Grundtypen und ein Attribut mit einem Referenztyp erstellt.

Verbinden wir nun unser kürzlich hinzugefügtes Formularelement mit einem der Details. Wählen Sie dazu das gewünschte Attribut aus der PathKData-Eigenschaft des Elements aus.

Danach werden die Eigenschaften DataPath und View ausgefüllt und das Element selbst wird in der Formularansicht angezeigt.

Achten Sie auf die Elementeigenschaft Sicht. Diese Eigenschaft bestimmt die Funktionalität des Eingabefeldes. Sie können für diese Eigenschaft verschiedene Werte auswählen.

Abhängig vom gewählten Wert wird die Funktionalität bestimmt. In den obigen Abbildungen ist der ausgewählte Wert – Eingabefeld, d.h. In dieses Eingabefeld können wir beliebige Werte eingeben und ggf. einen Wert auswählen Beschriftungsfeld, dann können wir nichts eingeben.

Dieser Eigenschaftswert Sicht Die Auswahl von Eingabefeldern ist praktisch, wenn Sie dem Benutzer nur Hilfeinformationen anzeigen müssen.

Fügen wir nun ein neues Formularelement mit Typ hinzu Eingabefeld und verbinde es mit den Requisiten DetailsDatumüber die uns bereits bekannte DataPath-Eigenschaft

Wie Sie sehen, hat sich das Erscheinungsbild des Eingabefelds geändert und auch die mögliche Werteauswahl für die View-Eigenschaft ändert sich.

Daraus schließen wir, dass die Funktionalität des Eingabefelds von der Art des Attributs abhängt.

Für Requisiten mit Typ Boolescher Wert Die folgenden View-Eigenschaftswerte sind verfügbar.

Und für Attribute mit einem Referenztyp stehen andere Werte der View-Eigenschaft zur Verfügung.

Ausführlichere Arbeiten mit Formularelementen anhand praktischer Beispiele finden Sie im Buch „Grundlagen der Entwicklung in 1C: Taxi“. Verwaltete Anwendungsentwicklung in 12 Schritten“.

Manchmal scheint es kompliziert und schwierig zu sein, die Programmiersprache in 1C zu lernen. Tatsächlich ist die Programmierung in 1C einfach. Meine Bücher helfen Ihnen, die Programmierung in 1C schnell und einfach zu meistern: und „Grundlagen der Entwicklung in 1C: Taxi“

Lernen Sie das Programmieren in 1C mit Hilfe meines Buches „Programmieren in 1C in 11 Schritten“

  1. Keine komplizierten Fachbegriffe.
  2. Über 700 Seiten praktisches Material.
  3. Zu jeder Aufgabe gibt es eine Zeichnung (Screenshot).
  4. Eine Sammlung von Hausaufgaben.
  5. Das Buch ist in klarer und einfacher Sprache geschrieben – für einen Anfänger.

Dieses Buch eignet sich für diejenigen, die bereits mit dem Programmieren begonnen haben und gewisse Schwierigkeiten mit diesem Thema haben, und für diejenigen, die schon lange programmieren, aber noch nie mit 1C-verwalteten Formularen gearbeitet haben.

  1. Ohne komplexe Fachbegriffe;
  2. Mehr als 600 Seiten praktisches Material;
  3. Zu jedem Beispiel gibt es eine Zeichnung (Screenshot);
  4. Das Buch wird per E-Mail im PDF-Format verschickt. Kann auf jedem Gerät geöffnet werden!

Aktionscode für 15 % Rabatt - 48PVXHeYu


Wenn Ihnen diese Lektion bei der Lösung eines Problems geholfen hat, sie Ihnen gefallen hat oder Sie sie nützlich fanden, dann können Sie mein Projekt unterstützen, indem Sie einen beliebigen Betrag spenden:

Sie können manuell bezahlen:

Yandex.Money - 410012882996301
Webgeld – R955262494655

Treten Sie meinen Gruppen bei.

Und Datenübertragungsobjekt zur Codestrukturierung, kontrollierte Form in der 1C 8.2-Umgebung.

Einführung

Beginnen wir mit einer kurzen Beschreibung des Konzepts des „verwalteten Formulars“ und verwandter Konzepte der 1C-Plattform. Plattformkenner sollten diesen Abschnitt vielleicht überspringen.

Im Jahr 2008 wurde eine neue Version der 1C-Plattform verfügbar: Enterprise 8.2 (im Folgenden als Managed Application bezeichnet), die die gesamte Arbeitsebene mit der Schnittstelle völlig verändert. Dazu gehören die Befehlsschnittstelle, Formulare und das Fenstersystem. Gleichzeitig ändert sich nicht nur das Modell zur Entwicklung der Benutzeroberfläche in der Konfiguration, sondern es wird auch eine neue Architektur zur Trennung der Funktionalität zwischen der Clientanwendung und dem Server vorgeschlagen.
Die verwaltete Anwendung unterstützt die folgenden Arten von Clients:

  • Thick Client (normaler und verwalteter Startmodus)
  • Dünner Kunde
  • Web-Client
Die verwaltete Anwendung verwendet Formulare, die auf neuer Technologie basieren. Sie heißen Verwaltete Formulare. Um den Übergang zu erleichtern, werden auch frühere Formulare (die sogenannten regulären Formulare) unterstützt, deren Funktionalität jedoch nicht weiterentwickelt wird und sie nur im Thick-Client-Startmodus verfügbar sind.
Die Hauptunterschiede verwalteter Formulare für einen Entwickler:
  • Deklarative, nicht „pixelweise“ Beschreibung der Struktur. Die konkrete Platzierung der Elemente erfolgt automatisch durch das System bei der Anzeige des Formulars.
  • Alle Funktionen des Formulars werden wie folgt beschrieben Einzelheiten Und Mannschaften. Details sind die Daten, mit denen das Formular arbeitet, und Befehle sind die auszuführenden Aktionen.
  • Das Formular läuft sowohl auf dem Server als auch auf dem Client.
  • Im Client-Kontext sind fast alle Anwendungstypen nicht verfügbar und dementsprechend ist es nicht möglich, die Daten in der Infobase zu ändern.
  • Für jede Methode oder Formularvariable muss diese angegeben werden Kompilierungsanweisung, Definieren des Ausführungsorts (Client oder Server) und Zugriff auf den Formularkontext.
Lassen Sie uns die Anweisungen zum Kompilieren von Formularmethoden auflisten:
  • &OnClient
  • &Auf dem Server
  • &OnServerWithout Context
  • &OnClientOnServerWithout Context
Lassen Sie uns das oben Gesagte veranschaulichen. Der Screenshot zeigt ein Beispiel eines verwalteten Formulars und seines Moduls im Entwicklungsmodus. Finden Sie die deklarative Beschreibung, Requisiten, Kompilierungsanweisungen usw.

Alle weiteren Diskussionen drehen sich um die rechte Seite der Abbildung, um die Strukturierung des Modulcodes und um die Prinzipien, mit denen Sie eine effektive Client-Server-Interaktion implementieren können.

Definieren wir das Problem

Es sind mehrere Jahre vergangen, seit die neue Version der 1C-Plattform aktiv genutzt wird und viele Lösungen (Konfigurationen) sowohl von 1C als auch von seinen zahlreichen Partnern veröffentlicht wurden.
Haben Entwickler in dieser Zeit ein gemeinsames Verständnis der Prinzipien der Client-Server-Interaktion bei der Erstellung von Formularen entwickelt und hat sich der Ansatz zur Implementierung von Softwaremodulen in den neuen architektonischen Realitäten verändert?

Schauen wir uns die Codestruktur (Formularmodul) in mehreren Formen derselben Standardkonfiguration an und versuchen, Muster zu finden.
Mit Struktur meinen wir Codeabschnitte (meistens handelt es sich dabei um Kommentarblöcke), die vom Entwickler den Gruppenmethoden und Kompilierungsanweisungen für diese Methoden zugewiesen werden.
Beispiel 1:
Abschnitt der Ereignishandler. Methode – auf dem Client. Methode – auf dem Server. Methode – auf dem Client. Abschnitt der Dienstprozeduren und -funktionen. Hilfsfunktionen zur Eingabesteuerung
Beispiel 2:
Serviceabläufe und Funktionen Zahlungsdokumente Werte Eventhandler
Beispiel 3:
Dienstprozeduren auf dem Server Dienstprozeduren auf dem Client Dienstprozeduren auf dem Server ohne Kontext Header-Ereignishandler Befehlsereignishandler
Beispiel 4:
Allzweckprozeduren Formular-Ereignishandler Prozeduren des Subsystems „Kontaktinformationen“.
Im Wesentlichen fehlt die Codestruktur, oder um es milde auszudrücken, sie ähnelt der in Forms 8.1:

  • Nicht informative Wörter „Allgemeines, Service, Hilfsprogramm“.
  • Scheue Versuche, Client- und Servermethoden zu trennen.
  • Methoden werden häufig nach Oberflächenelementen „Arbeiten mit dem tabellarischen Teil Produkte, Kontaktinformationen“ gruppiert.
  • Beliebige Anordnung von Methoden und Codegruppen. Event-Handler können beispielsweise in einem Formular oben stehen, in einem anderen unten, in einem dritten überhaupt nicht hervorgehoben usw.
  • Und vergessen wir nicht, dass dies alles in einer Konfiguration geschieht.
  • Ja, es gibt Konfigurationen, in denen die Worte „General, Service, Auxiliary“ immer an den gleichen Stellen stehen, aber...
Warum brauchen Sie eine Codestruktur?
  • Vereinfachung der Wartung.
  • Vereinfachen Sie das Lernen.
  • Aufzeichnen allgemeiner/wichtiger/erfolgreicher Grundsätze.
  • ...Ihre Option
Warum hilft der bestehende Entwicklungsstandard von 1C nicht?
Schauen wir uns die auf ITS-Disketten und in verschiedenen „Entwicklerhandbüchern“ veröffentlichten Prinzipien an, die beim Schreiben eines verwalteten Formulars empfohlen werden.
  • Minimieren Sie die Anzahl der Serveraufrufe.
  • Maximale Rechenleistung auf dem Server.
  • Nicht kontextbezogene Serveraufrufe sind schneller als kontextbezogene.
  • Programm mit Blick auf die Client-Server-Kommunikation.
  • usw.
Das sind Slogans, die absolut wahr sind, aber wie setzt man sie um? Wie kann die Anzahl der Aufrufe minimiert werden? Was bedeutet es, im Client-Server-Modus zu programmieren?

Designmuster oder Generationenweisheit

Client-Server-Interaktion wird seit Jahrzehnten in verschiedenen Softwaretechnologien eingesetzt. Die Antwort auf die im vorherigen Abschnitt skizzierten Fragen ist seit langem bekannt und lässt sich in zwei Grundprinzipien zusammenfassen.
  • Fernfassade(im Folgenden als Remote Access Interface bezeichnet)
  • Datenübertragungsobjekt(im Folgenden Datentransferobjekt genannt)
Ein Wort von Martin Fowler, seine Beschreibung dieser Prinzipien:
  • … Jedes potenziell für den Fernzugriff vorgesehene Objekt muss über Folgendes verfügen: Schnittstelle mit geringer Granularität, wodurch die Anzahl der Aufrufe minimiert wird, die zum Ausführen einer bestimmten Prozedur erforderlich sind. ... Anstatt eine Rechnung und alle ihre Positionen einzeln anzufordern, müssen Sie alle Rechnungspositionen in einer Anfrage lesen und aktualisieren. Dies wirkt sich auf die gesamte Struktur des Objekts aus... Denken Sie daran: RAS-Schnittstelle enthält keine Domänenlogik.
  • ...wenn ich eine fürsorgliche Mutter wäre, würde ich meinem Kind auf jeden Fall sagen: „Schreibe niemals Datentransferobjekte!“ In den meisten Fällen sind Datenübertragungsobjekte nichts anderes als aufgeblähter Feldsatz... Der Wert dieses ekelhaften Monsters liegt allein in der Möglichkeit Übertragen Sie mehrere Informationen in einem Anruf über das Netzwerk- eine Technik, die für verteilte Systeme von großer Bedeutung ist.
Beispiele für Vorlagen in der 1C-Plattform
Die Anwendungsprogrammierschnittstelle, die dem Entwickler bei der Entwicklung eines verwalteten Formulars zur Verfügung steht, enthält viele Beispiele dieser Prinzipien.
Zum Beispiel die OpenForm()-Methode, eine typische „raue“ Schnittstelle.
OpeningParameters = Neue Struktur("Parameter1, Parameter2, Parameter3", Wert1, Wert2, Wert3); Form = OpenForm(FormName, OpeningParameters);
Vergleichen Sie mit dem in Version 8.1 übernommenen Stil.
Form = GetForm(FormName); Form.Parameter1 = Wert1; Form.Parameter2 = Wert2; Form.Open();

Im Kontext eines verwalteten Formulars gibt es viele „Datenübertragungsobjekte“. Sie können auswählen systemisch Und Vom Entwickler definiert.
Systemmodelle modellieren ein Anwendungsobjekt auf dem Client in Form eines oder mehrerer Formulardatenelemente. Es ist unmöglich, sie ohne Bezugnahme auf die Formulardetails zu erstellen.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Die Konvertierung von Systemdatenübertragungsobjekten in Anwendungstypen und umgekehrt erfolgt mit folgenden Methoden:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Bei der Anpassung einer bestehenden Lösung kommt häufig eine explizite Konvertierung zum Einsatz. Methoden können Eingabeparameter wie ValueTable anstelle von FormDataCollection erwarten (Funktionen verwenden), oder die Methode wurde im Kontext eines Anwendungsobjekts definiert und ist für den direkten Aufruf aus dem Formular nicht mehr verfügbar.
Beispiel 1C v8.1:
// auf dem Client im Kontext des Formulars FillUserCache(DepartmentLink)
Beispiel 1C v8.2:
// auf dem Server im Kontext des Formulars ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueFormAttributes(ProcessingObject, "Object");

Datenübertragungsobjekte, deren Struktur vom Entwickler festgelegt wird, sind eine kleine Teilmenge der sowohl auf dem Client als auch auf dem Server verfügbaren Typen. Am häufigsten werden als Parameter und Ergebnisse von Methoden einer „vergröberten“ Schnittstelle verwendet:

  • Primitive Typen (String, Zahl, Boolescher Wert)
  • Struktur
  • Korrespondenz
  • Array
  • Links zu Anwendungsobjekten (eindeutige Kennung und Textdarstellung)
Beispiel: Die Methode akzeptiert eine Liste von Anweisungen zur Statusänderung und gibt eine Beschreibung der Fehler an den Client zurück.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [Bestellung][Fehlerbeschreibung] Für jede Bestellung aus dem Auftragszyklus StartTransaction(); Versuchen Sie es mit DocOb = Order.GetObject(); …. andere Aktionen, nicht nur mit der Bestellung möglich... Exception CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndAttempt; EndCycle; Rückgabefehler; EndFunction // ServerChangeOrderStatus()

Den Code strukturieren

Die Hauptziele, die das verwaltete Formularmodul widerspiegeln sollte, und Lösungsansätze.
  • Klare Trennung von Client- und Servercode. Vergessen wir nicht, dass es sich zum Zeitpunkt der Ausführung um zwei interagierende Prozesse handelt, die jeweils über deutlich unterschiedliche verfügbare Funktionen verfügen.
  • Eindeutige Identifizierung der RAS-Schnittstelle, welche Servermethoden können vom Client aufgerufen werden und welche nicht? Die Namen von Remote-Schnittstellenmethoden beginnen mit dem Präfix „Server“. Dadurch können Sie beim Lesen des Codes sofort erkennen, wie die Kontrolle an den Server übertragen wird, und die Verwendung kontextbezogener Hilfe wird vereinfacht. Beachten Sie, dass die offizielle Empfehlung (ITS) die Benennung von Methoden mit Postfixen vorschlägt, beispielsweise ChangeOrderStatusOnServer(). Wir wiederholen jedoch, dass nicht alle Servermethoden vom Client aufgerufen werden können und daher die logische Zugänglichkeit wichtiger ist als der Kompilierungsspeicherort. Deshalb markieren wir mit dem Präfix „Server“ nur die Methoden, die dem Client zur Verfügung stehen; nennen wir die Beispielmethode ServerChangeOrderStatus().
  • Lesbarkeit. Geschmackssache, wir übernehmen den Auftrag, wenn das Modul mit den Verfahren zum Erstellen eines Formulars auf dem Server und den Fernzugriffsmethoden beginnt.
  • Wartbarkeit. Es muss ein klarer Ort zum Hinzufügen von neuem Code vorhanden sein. Ein wichtiger Punkt ist, dass vom Konfigurator automatisch erstellte Methodenvorlagen am Ende des Moduls hinzugefügt werden. Da Ereignishandler für Formularelemente meist automatisch erstellt werden, befindet sich der entsprechende Block an letzter Stelle, um nicht jeden Handler an eine andere Stelle im Modul zu ziehen.
Nachfolgend finden Sie den Grundaufbau des Moduls, das die aufgeführten Ziele umsetzt.
  • Grafische Option – zeigt deutlich den Hauptausführungsablauf.
  • Die Textoption ist ein Beispiel für einen Vorlagenentwurf zum schnellen Einfügen einer Struktur in ein neues Formularmodul.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datum=""/> // <Описание> // // ///////////////////////////////////////////// // ///////////////////////// // MODULVARIABLEN ///////////////// // /////////////////////////////////////////// //// ////////// // AUF DEM SERVER //******* EREIGNISSE AUF DEM SERVER ******* &Auf dem Server Prozedur bei Erstellung auf dem Server (Fehler, Standardverarbeitung) / /Fügen Sie den Inhalt des Handlers ein. Ende der Prozedur //******* REMOTE ACCESS INTERFACE ******* //******* GESCHÄFTSLOGIK AUF DEM SERVER ******* ///////// /////////////////////////////////////////////////////////////////////// /////// /////////////////// // GEMEINSAME METHODEN VON CLIENT UND SERVER /////////////// /////// ///////////////////////////////////////////////////////////////////////// ///// //////// // AUF DEM KUNDEN //******* GESCHÄFTSLOGIK AUF DEM KUNDEN ******* //******* TEAM * ****** //******* KUNDENVERANSTALTUNGEN ******* ///////////////////////// ///// /////////////////////////////////////////////////////////////////////////// // / / HAUPTPROGRAMMBETREIBER

Verwandte Fragen
Abschließend werden wir einige Bereiche skizzieren, über die man bei der Programmierung der Client-Server-Interaktion nachdenken sollte.
  • Implementierungsoptionen für die Fernzugriffsschnittstelle. Asynchronität, Detaillierungsgrad...
  • Caching. 1C hat eine erfolglose Architekturentscheidung getroffen, indem es Caching nur auf der Ebene der Aufrufmethoden allgemeiner Module einführte und keine Kontrollfunktionen (Relevanzzeit, Zurücksetzen bei Bedarf) bereitstellte.
  • Implizite Serveraufrufe. Vergessen Sie nicht die technologischen Besonderheiten; viele „harmlose“ Vorgänge auf dem Client veranlassen die Plattform, Kontakt mit dem Server aufzunehmen.


Verwandte Veröffentlichungen