HotXLS erzeugt aus Delphi über AddCamera Excel-Kamera-Objekte auf XLSX-Arbeitsblättern. Ein Kamera-Objekt ist ein Bild, das dauerhaft mit einem Zellbereich verknüpft ist: Excel rendert es jedes Mal aus dem Quellbereich neu, wenn die Arbeitsmappe geöffnet wird oder sich die Quelle ändert, sodass ein Dashboard eine Live-Ansicht einer Tabelle zeigen kann, die auf einem anderen Blatt liegt, in beliebiger Größe, bei Bedarf auch gedreht
Das Feature existiert in Excel als das Kamera-Werkzeug, ein Button, den die meisten Benutzer nie gesehen haben, weil er standardmäßig nicht im Menüband liegt. Es löst ein echtes Dashboard-Problem besser als die Alternativen: Ein kopierter Bereich veraltet, ein Diagramm kann keinen beliebigen Zellinhalt zeigen, und ein von Hand eingefügtes verknüpftes Bild lässt sich nicht per Code erzeugen. Ein Kamera-Objekt ist das eine Konstrukt, das sowohl lebendig als auch beliebig ist
Wo ist das dokumentiert, und warum ist das wichtig?
Die Hauptspezifikation für Tabellenkalkulationen beschreibt Kamera-Objekte nicht; sie werden als Implementierungsdetail behandelt. Die maßgebliche Beschreibung findet sich in der Drawing-Markup-Dokumentation unter der Überschrift Camera Tool, und dieses Wissen erspart einen Nachmittag Suche im falschen Dokument
Strukturell ist ein Kamera-Objekt ein gewöhnliches Bildelement, dessen nichtvisuelle Bildeigenschaften eine Erweiterungsliste tragen. Die Erweiterung wird durch eine feste GUID identifiziert, und darin hält ein Element aus dem 2010er-Drawing-Namespace zwei Dinge fest: den Quellbereich als absolute Referenz im A1-Stil, optional blattqualifiziert, sowie eine Formkennung. Alles andere am Bild ist normal
Eines erstellen
Es gibt zwei Überladungen, weil zwei Arten, einen Bereich zu benennen, praktisch sind. Die Textform nimmt die Referenz genau so, wie sie gespeichert wird, was für eine blattübergreifende Quelle gewünscht ist. Die Koordinatenform nimmt vier Zellkoordinaten auf demselben Blatt und baut die absolute Referenz für Sie:
uses
lxHandleX;
var
Book: TXLSXWorkbook;
Dashboard: TXLSXWorksheet;
Cam: TXLSXImage;
begin
Book := TXLSXWorkbook.Create;
try
if Book.Open('reporting.xlsx') <> 1 then
Exit;
Dashboard := Book.Sheets[0];
// Live-Ansicht von Data!$B$2:$D$4, platziert über B10:F20 auf dem Dashboard
Cam := Dashboard.AddCamera('Data!$B$2:$D$4', 10, 2, 20, 6);
// Die Platzierungsbox verwendet standardmäßig Excels eigene 64-px-Spalten und
// 20-px-Zeilen; passen Sie die gezeichnete Größe bei Bedarf danach in EMU an
Cam.WidthEMU := Round(12.5 * 914400 / 2.54); // 12.5 cm
Cam.HeightEMU := Round(6.0 * 914400 / 2.54);
Book.SaveAs('reporting-dashboard.xlsx');
finally
Book.Free;
end;
end;Das zurückgegebene Objekt ist ein normales Bildobjekt mit einer zusätzlichen Eigenschaft, CameraRange, die genau dann nicht leer ist, wenn das Bild eine Kamera ist. So erkennen Sie auch Kameras in einer Arbeitsmappe, die Sie nicht selbst erstellt haben: die Bilder aufzählen und die Eigenschaft prüfen
Warum muss das Platzhalterbild nicht echt sein?
Jedes Bild in einem XLSX-Paket benötigt einen Bildteil, und ein Kamera-Objekt bildet keine Ausnahme. Aber Excel ignoriert dieses Bild: Beim Laden rendert es den verknüpften Bereich neu und malt das Ergebnis. Die eingebetteten Bytes existieren rein als Anzeige-Cache für Werkzeuge, die das Kamera-Verhalten nicht implementieren
Diese Tatsache entfernt ein ganzes Subsystem aus der Implementierung. Es besteht keine Notwendigkeit, den Quellbereich zu rastern, keine Notwendigkeit für eine Rendering-Engine, um den Schnappschuss zu erzeugen, und kein Risiko, dass das zwischengespeicherte Bild vom lebendigen Bild in Excel abweicht. HotXLS schreibt eine minimale Platzhalter-Metadatei — ein Header-Datensatz und ein End-of-File-Datensatz, insgesamt 108 Bytes —, was das Paket strukturell vollständig hält und nichts kostet
Eine Konsequenz, die Sie einplanen sollten: Ein Betrachter, der XLSX rendert, ohne Kamera-Objekte zu implementieren, zeigt den Platzhalter, der leer ist. Werden Ihre Arbeitsmappen von einem solchen Werkzeug konsumiert, ist ein Kamera-Objekt das falsche Konstrukt, und ein gerendertes Bild des Bereichs ist das richtige
Die Einheitenumrechnung, bei der man leicht Fehler macht
Zeichnungsgeometrie in Open XML wird in English Metric Units gemessen, wobei ein Zoll 914.400 EMU und ein Zentimeter 360.000 sind. Metadatei-Header erfassen ihren Rahmen jedoch in Einheiten von 0,01 Millimeter. Die Umrechnung zwischen beiden ist eine Division durch 360
Es lohnt sich, das zu benennen, denn der Fehler ist still. Stattdessen über Pixel bei 96 DPI umzurechnen — mit 2540 multiplizieren und durch 9525 teilen — erzeugt einen 96-mal zu großen Wert, und nichts weist ihn zurück: Das Paket ist gültig, das Bild wird vom Anker korrekt platziert, und nur der deklarierte Rahmen der Metadatei ist Unsinn. Das EMU-Modell und sein Rundungsverhalten sind unter Bildgeometrie, EMU-Einheiten und Skalierung behandelt
Eine Arbeitsmappe, die bereits Kameras enthält, über Öffnen und Speichern hinweg erhalten
Das Öffnen und Speichern einer Arbeitsmappe erhält Kamera-Objekte, einschließlich des Erweiterungselements und seiner Bereichsreferenz. Das ist wichtiger als das Erstellen: Die meisten Arbeitsmappen mit Kamera-Objekten wurden von einem Analysten in Excel erstellt, und eine Bibliothek, die sie beim Speichern stillschweigend in gewöhnliche Bilder umwandelt, hat das lebendige Verhalten zerstört, auf das sich der Analyst verlassen hat
// Prüfen, welche Bilder Kameras sind und worauf sie zeigen
for I := 0 to Sheet.Images.Count - 1 do
if Sheet.Images[I].CameraRange <> '' then
Writeln(Format('camera %d -> %s',
[I, Sheet.Images[I].CameraRange]));Wenn Sie Dashboards programmatisch erzeugen, ist die Prüfung zugleich der Regressionstest: Nach einem Speichern-und-erneut-öffnen-Zyklus muss dieselbe Anzahl von Kameras auf dieselben Bereiche zeigen. Die allgemeine Behandlung von Bildern und Zeichnungen, einschließlich des Ankermodells, das sie positioniert, ist unter Diagramme, Bilder und Zeichnungen behandelt
Wann eine Kamera die Alternativen schlägt
Verwenden Sie ein Kamera-Objekt, wenn dieselbe lebendige Tabelle auf mehreren Blättern in unterschiedlichen Größen erscheinen muss, wenn ein Drucklayout einen Bereich eines Blatts neben Bereichen anderer Blätter zusammengesetzt benötigt, oder wenn ein Zusammenfassungsblock andernorts vorgenommenen Bearbeitungen folgen soll, ohne dass eine Formel jede Zelle einzeln verknüpft
Bevorzugen Sie gewöhnliche Formeln, wenn das Ziel eine Handvoll Zellen ist, denn eine blattübergreifende Formel ist einfacher, und jedes Werkzeug versteht sie. Bevorzugen Sie ein Diagramm, wenn die Daten wirklich eine Reihe sind statt eines formatierten Blocks. Und bevorzugen Sie ein gerendertes Bild, wenn die Arbeitsmappe von anderen Werkzeugen als Excel konsumiert wird oder wenn sich der Schnappschuss nach der Auslieferung nicht mehr ändern darf — ein archivierter Bericht sollte nicht lebendig sein
Ein Layout-Hinweis aus der Praxis: Eine Kamera zeigt den Quellbereich exakt so formatiert, wie er ist, einschließlich verbundener Zellen, bedingter Formatierung und Spaltenbreiten. Ein sauber wirkender Dashboard-Block beginnt daher damit, den Quellbereich so zu formatieren, als wäre er die fertige Ausgabe, dieselbe Disziplin, die unter verbundene Zellen und Berichtsvorlagen-Layout beschrieben ist
Kamera-Objekte, Zeichnungen und der dahinterliegende XLSX-Paket-Writer werden in einer Bibliothek für Delphi und C++Builder ausgeliefert; die vollständige Funktionsliste finden Sie auf der HotXLS-Delphi-Tabellenkalkulationskomponentenseite