Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Objektmodell
In diesem Berichtbindungsszenario wird ReportDocument verwendet (siehe Berichtbindung mit ReportDocument-Objektmodell).
Ort des Berichts
Berichte wurden in das Projekt eingebettet.
.gif) Anmerkung |
|---|
In früheren Versionen dieser Dokumentation wurden eingebettete Berichte als Berichte mit "strikter Typisierung" bezeichnet. Ab jetzt werden die einem Visual Studio-Projekt hinzugefügten bzw. darin importierten Berichte mit dem Hauptbegriff "eingebettet" beschrieben. |
Beschreibung
In diesem Szenario wird ein Bericht in das Projekt eingebettet. Um einen Bericht einzubetten, erstellen Sie entweder mit dem eingebetteten Crystal Report Designer (aus Visual Studio) einen neuen Bericht oder importieren einen vorhandenen Bericht in das Projekt. Beim Erstellen oder Importieren des Berichts wird automatisch eine Berichtwrapperklasse zur Darstellung des Berichts generiert. Diese Wrapperklasse hat denselben Namen wie der Bericht. Sie wird von der Basisklasse ReportDocument abgeleitet und erbt folglich alle Eigenschaften und Methoden von ReportDocument, wodurch sie zum Bestandteil des ReportDocument-Objektmodells wird.
Die meisten Anwender von Crystal Reports für Visual Studio verwenden dieses Szenario für die Berichtbindung. da es bei weitem am einfachsten zu implementieren ist:
- Fügen Sie dem Projekt einen Bericht hinzu. Dadurch wird automatisch eine Berichtwrapperklasse erstellt.
- Instantiieren Sie die Berichtwrapperklasse.
- Weisen Sie diese Klasse der ReportSource-Eigenschaft des CrystalReportViewer-Steuerelements zu.
Pro
- Zusätzliche Sicherheit: Der Bericht wird eingebettet und folglich als Teil der Anwendung weitergegeben.
- Umfangreiche programmatische Interaktion: Bietet Zugriff auf das leistungsfähige ReportDocument-Objektmodell.
- Zusätzliche Sicherheit: Bietet die größtmögliche Kontrolle für den Zugriff auf Berichtquellen.
- Am häufigsten verwendet: Nach Meinung der meisten Entwickler bietet dieses Szenario die meisten Vorteile.
Contra
- Zusätzliche Wartung: Geänderte Berichte müssen neu kompiliert, und die Anwendung muss neu verteilt werden.