TXFAEventBinding

Unit: HPDFXFAEventScript

Deklaration

TXFAEventBinding= record
  Name, ClassName: AnsiString;
  ParentIndex: Integer;
  Value, Presence, Access: AnsiString;
  InstanceCount, InstanceGroup: Integer;
  MinInstances, MaxInstances: Integer;
  DefaultValue, DefaultPresence, DefaultAccess: AnsiString;
  Repeated: Boolean;
  Identity, ScriptSource, Locale, EventActivity: AnsiString;
  Domain: TXFAEventBindingDomain;
  DataIdentity: AnsiString;
  DataBindingEnabled: Boolean;
  Attributes, DefaultAttributes: TXFAEventAttributes;
  PropertyPath: AnsiString;
  PropertyOwnerIndex: Integer;
  XML, DefaultXML: AnsiString;
  DataBindingRef, DataContextIdentity: AnsiString;
  DataBindingExplicit: Boolean;
end;

Verhalten

Beschreibt einen virtuellen Ereignis-Host-Knoten; jedes tatsächliche wiederholte Subformular-Vorkommen erhält ein eigenes Binding und eigene Kinder

ParentIndex wählt sein übergeordnetes Binding, oder -1 für die Wurzel; Value, Presence und Access beschreiben den aktuellen Vorkommenszustand

InstanceGroup identifiziert Bindings, die derselbe Instance Manager verwaltet, während InstanceCount und Vorkommensgrenzen die Manager-Grenzen beschreiben

Template-Defaults initialisieren neue Instanzen; Repeated identifiziert Knoten mit einer occur-Deklaration

TXFAWidgetRuntime baut diese Records aus dem Template und dem aktuellen Datasets-Kontext, bevor die Engine ausgeführt wird

Identity ist die stabile Host-Identität dieses Vorkommens; ScriptSource enthält JavaScript für ein Skriptobjekt, das innerhalb von variables deklariert ist

Eine leere Identity nutzt eine eindeutige Binding-Index-Identität; liefere stabile explizite Identitäten, wenn sich die Binding-Reihenfolge ändern kann, damit erhaltene Referenzen weiterhin dasselbe Vorkommen adressieren

Locale trägt das optionale locale-Attribut des Knotens als UTF-8-Text; der ausführende Knoten erbt den nächsten nichtleeren Vorfahrenwert, eine leere Kette wählt die User-Locale

EventActivity liefert xfa.event.name für das ausführende Binding; TXFAWidgetRuntime setzt Event-Activities sowie Calculate- oder Validate-Kontextnamen, während leere Bindings auf niedrigerer Ebene event verwenden

Domain unterscheidet Formularknoten von nativen datasets-, dataGroup- und dataValue-Knoten; der Default xebdForm erhält bestehende Aufrufer

DataIdentity referenziert die stabile Identität eines anderen Bindings, um ein Formularfeld oder Subformular mit seinem Datenknoten zu verbinden; Feld- und Datenwert-Lesezugriffe teilen sich dann einen Live-Wert

DataBindingEnabled erlaubt die implizite Datenknoten-Erzeugung, wenn ein wiederholter Formularprototyp keine bestehende Data-Bindung hat; Runtime-Felder mit bind match=none lassen es auf False und legen keinen synthetischen Datenknoten offen

Das Data-Domain-InstanceGroup zeichnet das gleichnamige Geschwister-Vorkommen für die native virtuelle Zielveröffentlichung auf; Data-Bindings legen keine Formular-Instance-Manager offen

Attributes enthält effektive aktuelle Property-Attribute; DefaultAttributes enthält Template-Attribute für einen neu geklonten Property-Knoten

Der Property-Domain-Name behält das tatsächliche name-Attribut, meist leer; sein ClassName liefert die SOM-Komponente, und seine Elternindizes bewahren Property-Hierarchie und lokale Geschwister-Vorkommen

PropertyPath und PropertyOwnerIndex identifizieren eine rein formularseitige Property, die im Template fehlt; der Pfad verwendet Klassen-Vorkommenskomponenten, und der Owner-Index wählt das native Formularvorkommen im selben Binding-Array

Runtime-Bindings nur für Formulare legen aktuelle native Attribute offen, während ihre DefaultAttributes Schema-Defaults nutzen; das Klonen eines wiederholten Prototyps erzeugt so Default-Property-Werte, statt den Override einer anderen Instanz zu erben

Lasse PropertyPath für bestehende Bindings deklarierter Properties leer; der zugehörige Owner-Index bleibt dann ungenutzt

Bei exData ist XML das aktuelle serialisierte UTF-8-Element, und DefaultXML liefert Template-Inhalte für eine neue wiederholte Instanz

Ein exData-Binding mit leerem XML startet von einem leeren nativen exData-Element; formularseitiges DefaultXML bleibt leer, damit ein neues Vorkommen nicht den importierten Fremdinhalt einer anderen Instanz erbt

XML-Eingabestrings zählen zum Byte-Budget des Ereigniskontexts; saveXML und loadXML nutzen validiertes Replay nativer Antworten und veröffentlichen über xeakLoadXML

Data-Domain-XML trägt die begrenzten flachen nativen XML-Metadaten der Runtime: Elementname, Namespace, Wert, Attribute, Namespace-Deklarationen, geordneten Nichttext-Inhalt und Kindpositionen; DefaultXML bleibt bei Datenknoten ungenutzt

Die Metadaten enthalten einen Knoten und seine direkten Text-, Kommentar- und Processing-Instruction-Kinder und vermeiden so einen duplizierten Nachfahren-Subbaum pro Data-Binding

DataBindingRef ist der getrimmte dataRef-Selektor; DataBindingExplicit unterscheidet eine explizit leere dataRef von einer impliziten Feldnamen-Bindung

DataContextIdentity identifiziert den tatsächlichen nativen Datenbereich des Felds unabhängig von DataIdentity, das sein ausgewähltes Blatt identifiziert

Diese Felder lassen XML-Importe Bindings sofort gegen das frische Data DOM neu bewerten, einschließlich neu verfügbarer Ziele sowie Nachfahren-, Wildcard-, Klassen- und Index-Auswahlen

Normale Anwendungen nutzen TXFAWidgetRuntime, um native Bindings zu bauen; Aufrufer auf niedrigerer Ebene können XML-Metadaten für rein skalare Datenknoten weglassen und die neuen Binding-Felder auf ihren Default-Werten lassen

Verwandte APIs

Interaktive Dynamic-XFA-Widget-Runtime, FormCalc-Funktionen und XFA Packet DOM