Externe Arbeitsmappenbezüge

Übersicht

Tabellenkalkulationsmodelle beziehen häufig Daten aus sekundären Arbeitsmappen über Querverweis-Formeln; HotXLS unterstützt das Analysieren, Schreiben und Erhalten externer Arbeitsmappenbezüge sowohl in BIFF8- (klassisches XLS) als auch in OpenXML-Dokumenten (XLSX)

Arbeitsbereich für Live-Arbeitsmappen

TXLSWorkbookWorkspace in lxWorkbookWorkspace ist die gemeinsame Identitäts- und Registrierungszentrale für externe Live-Arbeitsmappen; sowohl TXLSWorkbook als auch TXLSXWorkbook stellen CreateWorkspaceWorkbook bereit und besitzen eine ExternalWorkspace, die ihre Formelauswerter verwenden, während eine über TXLSXWorkbook geöffnete ODS-Arbeitsmappe über denselben Adapter die OpenDocument-Engine-Art meldet

var
  Host, Target: TXLSXWorkbook;
begin
  Host.ExternalWorkspace.Add(
    '..\Data\Target.xlsx',
    '..\Data\Target.xlsx',
    'C:\Models\Host.xlsx',
    Target.CreateWorkspaceWorkbook);

  // The compatibility facade maps an unambiguous name to the
  // relationship target already stored in Host.ExternalLinks
  Host.RegisterExternalWorkbook('Target.xlsx', Target);

  // The matching call revokes a facade-level registration
  Host.UnregisterExternalWorkbook('Target.xlsx');
end;

Klassische Arbeitsmappen verwenden dieselben Kompatibilitätsmethoden mit TXLSWorkbook-Zielen; RegisterExternalWorkbook und UnregisterExternalWorkbook verwalten nur das Name-Mapping auf Fassadebene, während ExternalWorkspace.Remove und Clear die Arbeitsbereichs-Registrierungen selbst widerrufen. Engine-übergreifende Aufrufer fügen beliebige Classic-, XLSX- oder ODS-Adapter direkt zu ExternalWorkspace hinzu

• Die Identitätsnormalisierung ist lexikalisch und ignoriert Groß-/Kleinschreibung, erhält Pfade und Erweiterungen, löst relative Ziele gegen die Quellidentität des Besitzers auf, reduziert Dot-Segmente und führt keinen Dateisystem- oder Netzwerkzugriff aus
• Exakte Identitäten und explizite Aliasse werden zuerst aufgelöst; eine Suche nur über den Basisnamen gelingt nur dann, wenn genau eine verbundene Registrierung passt, andernfalls gibt Resolve xlswrsConflict zurück
• Add weist Kollisionen bei exaktem Schlüssel, Alias und doppelten Arbeitsmappen zurück; unterschiedliche vollständige Pfade und unterschiedliche Erweiterungen können koexistieren
• Remove und Clear widerrufen Registrierungen, während die direkte Zerstörung eines Classic- oder XLSX-Ziels dessen Adapter trennt und auf aktive Leser wartet, bevor das Modell freigegeben wird
• Externe Arbeitsblätter werden anhand des deklarierten Namens aufgelöst, bevor auf die 1-basierte Position als Fallback zurückgegriffen wird, sodass die Blattreihenfolge der Zielarbeitsmappe nicht zum Quell-Verknüpfungsverzeichnis passen muss
• Der Formelauswerter liest zuerst eine aufgelöste Live-Arbeitsmappe und fällt anschließend auf den typisierten Cache der Host-Datei zurück; Classic-XLS-Hosts dekodieren dünn besetzte XCT- und CRN-Werte, während XLSX-Hosts den Cache externer Verknüpfungen verwenden, den das Paketmodell bereits führt
• OnLoadWorkbook ist eine optionale, kontrollierte Ressourcenanforderung; standardmäßig ist sie nil, sodass die Neuberechnung weiterhin keinen Dateisystem- oder Netzwerkzugriff ausführt, sofern Anwendungscode diese Richtlinie nicht explizit bereitstellt
• Jede normalisierte Identität ruft den Loader höchstens einmal auf, bis ResetLoadAttempts erfolgt; gleichzeitige Top-Level-Anfragen teilen sich das In-Flight-Ergebnis, einschließlich typisierter Not-Found- und Fehlerergebnisse, statt dieselbe Ressource wiederholt zu öffnen
• MaxLoadDepth steht standardmäßig auf 16 und MaxWorkbookCount auf 64; Wiedereintritt mit derselben Identität, verschachtelte Abhängigkeiten von einer bereits in Bearbeitung befindlichen Identität, ausgeschöpfte Tiefe und ausgeschöpftes Arbeitsmappenkontingent liefern typisierte Diagnosen, statt in einem Ladezyklus zu blockieren
• ODF-External-Source-IRIs bleiben vollständige lexikalische Identitäten, einschließlich URI-Schemata und maskierter Zeichen, autorisieren aber niemals impliziten Datei- oder Netzwerkzugriff
• Ein Identitätskonflikt bleibt #REF!, damit veraltete Cachedaten keine mehrdeutige Route verschleiern können; eine Zelle ohne Cache-Eintrag ergibt nur dann einen leeren Wert, wenn die Datei für dieses Blatt einen gültigen Cache deklariert

Resolve führt zuerst die registrierte Suche und danach das optionale kontrollierte Laden aus; das Ergebnis ist ein TXLSWorkspaceResolveStatus (xlswrsResolved, xlswrsNotFound, xlswrsConflict, xlswrsDisconnected, xlswrsLoadNotFound, xlswrsLoadLimit, xlswrsLoadLoop oder xlswrsLoadError), und ResolveWithLoader liefert zusätzlich eine TXLSWorkspaceLoadDiagnostic, die einen TXLSWorkspaceLoadDiagnosticCode mit einem TXLSWorkspaceLoadResponseStatus (xlswlrsNotFound, xlswlrsResolved, xlswlrsError) koppelt, um nicht gefunden, Loader-Fehler, getrenntes Ergebnis, Tiefe- oder Arbeitsmappenlimit, Identitäts-Wiedereintritt, gleichzeitige Abhängigkeit und Registrierungskonflikt als Ergebnisse zu unterscheiden. Der Loader-Callback erhält eine TXLSWorkspaceLoadRequest (Identität, Tiefe, Anzahl registrierter Arbeitsmappen, Limits) und antwortet mit einer TXLSWorkspaceLoadResponse

Recalculate meldet einen TXLSWorkspaceRecalcStatus, optional mit einer TXLSWorkspaceRecalcResult-Aufschlüsselung, und der Auswerter zeichnet die Herkunft je Zelle als TXLSWorkspaceRuntimeLookup auf (xlswrlInactive, xlswrlResolved, xlswrlFallbackCache oder xlswrlError), damit die Diagnostik einen Live-Lesevorgang von einem Cache-Fallback unterscheiden kann

Der IXLSWorkspaceWorkbook-Adapter legt EngineKind (Typ TXLSWorkspaceEngineKind: xlsweClassic, xlsweOpenXml oder xlsweOpenDocument), SourceIdentity, InstanceIdentity und Generation offen, prüft mit IsConnected die Verbundenheit, liest eine einzelne Zelle über TryGetCellValue (liefert einen typisierten TXLSWorkspaceCellStatus mit Wert, nicht gefunden, ungültiger Referenz, getrennt oder Fehler plus einem Flag für außerhalb des verwendeten Bereichs), aktualisiert das Modell mit Recalculate und trennt sich mit Disconnect vom Arbeitsmappenmodell

Die Registrierung ergänzt AddAlias für zusätzliche Namen, die an eine registrierte Identität gebunden sind, TryResolve als exceptionsfreie Variante des Nachschlagens und BaseNameMatchCount, um vor der Wahl eines eindeutigen Ziels vorab zu sehen, wie viele verbundene Registrierungen denselben Basisnamen teilen

Arbeitsmappenübergreifender Abhängigkeitsgraph

BuildDependencyGraph macht einen Snapshot jedes registrierten Arbeitsmappenadapters und extrahiert Formelknoten aus Classic-XLS-, XLSX- und ODS-Modellen in einen gemeinsamen TXLSWorkspaceDepGraph; die Methode gibt False zurück und liefert keinen Teilgraphen, wenn ein registrierter Adapter keine Abhängigkeitsmetadaten bereitstellen kann

• Jeder Formelknoten behält seine kanonische Arbeitsmappenidentität, Arbeitsblattnamen und 1-basierte Arbeitsblattposition, 0-basierte Zellposition, das Array-Ausgaberechteck, die Volatilität und den Zustand nicht aufgelöster Referenzen
• Zell- und Rechteckbereichsreferenzen behalten kanonische Ziel-Arbeitsmappen- und Arbeitsblattidentitäten; Gesamtspalten-, Gesamtzeilen- und Gesamtblattreferenzen bleiben ein einziges Intervall, statt in Millionen von Zellen expandiert zu werden
• Lokale definierte Namen bleiben als symbolische Abhängigkeiten abfragbar und lassen sich zusätzlich zu ihren konkreten Zell- oder Bereichsabhängigkeiten auflösen, wenn sich die Definition statisch auflösen lässt
• Externe definierte Namen bewahren den External-Link-Slot, den deklarierten Namen, den optionalen Arbeitsblattgeltungsbereich und die kanonische Zielidentität, ohne DDE-, OLE- oder User-Function-Metadaten als Arbeitsmappennamen zu behandeln
• FindDependentsOfCell und der Aufbau der Graphenkanten verwenden Zeilenintervallbäume mit Abschneidung am Maximum-Ende; LastRangeCandidateChecks und EdgeCandidateChecks legen die Anzahl exakter Rechteckprüfungen offen, um die Performance verifizieren zu können
• Die Formelextraktion läuft unter Arbeitsmappen-Lese-Leases und scannt nur materialisierte Formelobjekte, sodass gepackte Wertspeicherung gepackt bleibt und die Graphenerzeugung Arbeitsmappengenerationen nicht verändert

Geplante Neuberechnung

Recalculate behält den gemeinsamen Graphen bei und baut ihn nur dann neu auf, wenn sich die Arbeitsbereichsregistrierung oder die Formelabhängigkeits-Generation einer Arbeitsmappe ändert; Wert-Generationen starten einen neuen Dirty-Durchlauf, und der Dirty-Status breitet sich über die arbeitsmappenübergreifenden Abhängigkeitskanten aus

var
  RecalcInfo: TXLSWorkspaceRecalcResult;
  Status: TXLSWorkspaceRecalcStatus;
begin
  Status := Workspace.Recalculate(RecalcInfo);
  if Status <> xlswrcOk then
    HandleWorkspaceCalculation(Status, RecalcInfo);
end;

• Strongly Connected Components werden auf Formelzellen berechnet, sodass Arbeitsmappen in beide Richtungen verlinken können und trotzdem zyklenfrei bleiben, solange ihre Zell-Abhängigkeitspfade keine Schleife bilden
• Echte Zyklusmitglieder und durch einen Zyklus blockierte Dirty-Nachfolger werden invalidiert und aus der topologischen Ordnung ausgeschlossen, damit veraltete Cachedaten nicht als erfolgreiche Ergebnisse ausgegeben werden
• Flüchtige oder statisch nicht auflösbare Referenzen erzwingen das für die Korrektheit erforderliche konservative Dirty-Verhalten, während stabile Graphen frühere Abhängigkeitsarbeit wiederverwenden
• Externe Lesevorgänge innerhalb eines Durchlaufs verwenden einen exakten Cache über Arbeitsmappeninstanz, Arbeitsblatt, Zeile und Spalte; eine geplante Formel invalidiert ihren Ausgabebereich vor der Auswertung, damit spätere Abhängige den neuen Wert sehen
• Der durchlauflokale Cache verleiht niemals Ressourcenautorität; registrierte Arbeitsmappen und der optionale, vom Aufrufer gesteuerte Loader bleiben die einzigen Live-Auflösungsquellen, gefolgt von typisierten Datei-Caches und #REF!
• TXLSWorkspaceRecalcResult legt offen, ob der Graph neu aufgebaut wurde, plus Zähler für Dirty, ausgewertet, invalidiert, Zyklus, blockiert, Cache-Treffer und Cache-Fehltreffer
• Der Status unterscheidet Erfolg, nicht unterstützte Adapter, getrennte Arbeitsmappen, Zirkularreferenzen, Berechnungsfehler und Arbeitsbereichsänderungen während des Durchlaufs
• Aufrufe von Recalculate auf demselben Arbeitsbereich werden serialisiert, sodass zwei Berechnungssitzungen den gemeinsamen Graphen oder Arbeitsmappen-Caches niemals gleichzeitig verändern
• Remove oder Clear dürfen laufen, während ein Durchlauf aktiv ist; der Durchlauf behält sichere Adapter-Snapshots und liefert xlswrcWorkspaceChanged, statt eine entfernte Registrierung zu dereferenzieren
• Die Zerstörung eines Arbeitsbereichs wartet, bis ihr aktiver Durchlauf abgeschlossen ist, während die Zerstörung einer registrierten Arbeitsmappe deren Adapter trennt und spätere Auflösungen sicher fehlschlagen lässt
• Loader-Fehler und Not-Found-Ergebnisse bleiben je normalisierter Identität einmal gecacht, bis ResetLoadAttempts erfolgt, und eine fehlgeschlagene Berechnung behält den lokalen Dirty-Zustand für einen expliziten Wiederholungsversuch
• Der vorgehaltene Graph macht einen unveränderten Folgedurchlauf proportional zur Anzahl registrierter Arbeitsmappen statt zur Formelanzahl; nicht-rekursive Komponentenanalyse und kompakte Bereichskanten halten tiefe und breite Modelle durch materialisierte Formelmetadaten im Rahmen

Externe definierte Namen abtrennen

ConvertExternalDefinedNamesToRefErrors stellt dieselbe öffentliche Operation auf TXLSWorkbook und TXLSXWorkbook bereit; sie gibt die Anzahl der arbeitsmappenweit und arbeitsblattweit gültigen Definitionen zurück, die durch natives #REF! ersetzt wurden

var
  Converted: Integer;
begin
  Converted := Workbook.ConvertExternalDefinedNamesToRefErrors;
  // External-link parts and ordinary cell formulas remain intact
end;

• Die Classic-XLS-Auswahl verwendet kompilierte BIFF-Referenz-Tokens und die XTI-Identität der unterstützenden Arbeitsmappe, sodass dreidimensionale Referenzen innerhalb derselben Arbeitsmappe und unsichere Token-Streams unverändert bleiben
• Die XLSX-Auswahl verwendet syntaxbewusste nummerische Arbeitsmappen-Slots in der Dokumentreihenfolge der Beziehungen und akzeptiert nur External-Link-Parts von Arbeitsmappen; DDE, OLE, unaufgelöste Slots, Tabellenreferenzen und Klammertext innerhalb von Strings sind ausgeschlossen
• Alle Ersetzungen werden vor der ersten Mutation vorbereitet und als eine einzige Schreiboperation festgeschrieben; ein zweiter Aufruf ist idempotent
• Namenstext, Arbeitsmappen- oder Arbeitsblattgeltungsbereich, Sichtbarkeit, Kommentare, Makro- und Built-in-Flags, unbekannte XLSX-Attribute und das Verzeichnis externer Verknüpfungen bleiben nach Konvertierung und Roundtrip erhalten
• Fehlerhafte und nicht unterstützte Definitionen bleiben wo möglich byte- oder texterhaltend und liefern stattdessen xlsDiagnosticDefinedNameConversionSkipped-Diagnosen, statt erraten zu werden
• Abhängige Formeln werden zum entsprechenden Excel-Fehlerwert neu berechnet, während ein gültiges gecachtes Ergebnis für eine gewöhnliche direkte externe Formel verfügbar bleibt, falls dessen Live-Arbeitsmappe später getrennt wird
• Die Operation ist Excel-spezifisch und interpretiert die OpenDocument-Semantik von Namensformeln nicht um

Externe Bezüge in klassischem XLS

In klassischen XLS-Arbeitsmappen werden externe Verknüpfungen im globalen Verzeichnisblock mittels EXTERNALBOOK- und EXTERNNAME-Datensätzen gespeichert; HotXLS hält diese Verzeichnisse während der Lese-/Schreibzyklen der Datei aufrecht und stellt sicher, dass Remote-Bereichsbezüge Modifikationsschleifen überdauern

Externe Beziehungen in XLSX

Bei OOXML-Arbeitsmappen wird die Zuordnung externer Verknüpfungen über Beziehungsteile verwaltet; prüfen Sie die nachfolgenden Details der unterstützenden Schnittstellen

• TXLSXExternalLinks-Klasse — API zum Auflisten und Aktualisieren externer Verknüpfungen der Tabellenkalkulation
• IXLSWorkbook-Schnittstelle — Arbeitsmappeneigenschaften der obersten Ebene
• IXLSRange.Formula-Eigenschaft — Arbeitsmappenübergreifende Formeln lesen und schreiben