Beobachtungen zum IRepository

Wir prüfen gerade die Verwendung von IRepository. Dabei sind folgende Fragen aufgekommen:

Verzeichnisse/ Ordner

Wie kann man Verzeichnisse (Ordner) erstellen? Ich könnte mir vorstellen, dass bei einer entsprechend hohen Anzahl von Reports ohne Verzeichnisse schnell die Übersicht verloren geht. Außerdem wäre dann ein Gruppierung von Reportbausteinen oder Unterreports in separaten Verzeichnissen möglich. Haben wir etwas übersehen? Vielleicht wäre es möglich den Pfad im Namen zu kodieren (Beispiel: \verkauf\bausteine\baustein1). Dann müssten die entsprechenden FileOpenDialog im Designer natürlich diese Hierachie noch entsprechend darstellen…

Mehrere Projekte in einem Job drucken

Wenn mehrere Projekte in einem Job gedruckt werden sollen, weisen wir der AutoProjectFile-Eigenschaft die jeweiligen Repository-Item-Ids Semikolon getrennt zu. Bei der Ausführung kommt dann allerdings folgende Fehlermeldung (LL26):

Das angegebene Pfadformat wird nicht unterstützt.
bei System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
bei System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
bei System.IO.FileInfo.Init(String fileName, Boolean checkHost)
bei System.IO.FileInfo..ctor(String fileName)
bei combit.Reporting.LlCore.LlPrintWithBoxStart(LlProject projectType, String projectFile, LlPrintMode printMode, LlBoxType boxType, IntPtr windowHandle, String title)
bei combit.Reporting.ListLabel.PrintReportFromRelationalDataSourceNewMode(IDataProvider dataSource, String projectFile, Boolean showFileSelect, LlPrintMode printMode, LlBoxType boxType, String dialogTitle, Boolean showPrintOptions, String tempPath)
bei combit.Reporting.ListLabel.AutoPrint(LlProject projectType, String projectFile, Boolean showFileSelect, LlPrintMode printMode, LlBoxType boxType, String dialogTitle, Boolean showPrintOptions, String tempPath)
bei combit.Reporting.ListLabel.Print(Object userData, LlProject projectType, String projectFile, Boolean showFileSelect, LlPrintMode printMode, LlBoxType boxType, IntPtr windowHandle, String dialogTitle, Boolean showPrintOptions, String tempPath)
bei combit.Reporting.ListLabel.Print(LlProject projectType, String projectFile, Boolean showFileSelect, LlPrintMode printMode)
bei combit.Reporting.ListLabel.Print(LlProject projectType, String projectFile, Boolean showFileSelect)
bei combit.Reporting.ListLabel.Print(LlProject projectType)
bei combit.Reporting.ListLabel.Print()
bei Diacom.TN.Client.Dialog.Development.TestDialog.TestDialogHf.mBtnReportTest_Click(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnClick(EventArgs e)
bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
bei System.Windows.Forms.Button.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
bei System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
bei System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
bei System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
bei System.Windows.Forms.Application.DoEvents()
bei Diacom.TN.Client.Service.DialogService.DialogBaseShowDialog(DialogBase pDialogBase)

Haben wir etwas vergessen oder ist das noch ein Bug?

Drawing(Path) - Funktion

Diese Funktion erstellt eine Grafik aus dem angegebenen Pfad. Hierbei wird scheinbar auf das echte Filesystem zugegriffen. Das finde ich auch gut, da so Grafiken, die auf einem Netzlaufwerk liegen (z.B. Artikelbilder) dynamisch referenziert werden können. Dennoch wäre es wahrscheinlich auch sinnvoll, das ganze zusätzlich (vielleicht über einen optionalen Parameter) auch auf das Repository (per Name) zugreifen zu lassen, um dort auch dynamisch Bilder auswählen zu können.
Ist das denkbar?

Was habt ihr so für Erfahrungen mit dem IRepository gemacht?

Bei mir verstärkt sich der Eindruck, dass die Kombination von Repository und Kombinationsdruck noch nicht unterstützt wird.

lListLabel.AutoProjectFile = "repository://{E6557715-BAC1-4499-BB0D-369B6EB6CDA2};repository://{6E7BD312-3DA6-4631-86A5-D0192D314E8F}"

führt zu der o.a. Exception.

Eventuell könnte hier das Problem liegen: combit.Reporting.LlCore.LlPrintWithBoxStart(…)
Hier gibt es eine Unterscheiderung zwischen Repository-Item und normalen Dateien:

if (this.m_Parent != null)
  {
    if (LlCore.IsRepositoryID(projectFile))
      this.m_Parent.LastProjectFile = projectFile;
    else
      this.m_Parent.LastProjectFile = new FileInfo(projectFile.Split(';')[0]).FullName;
  }

Das sieht für mich so aus, als wenn das Splitten von mehreren Projekten nur für File basierte Projekte umgesetzt ist.

Ich würde mich freuen, wenn jemand von combit das bestätigen könnte. Dann könnte ich ausschließen, dass ich noch irgendetwas übersehen habe. Vielen Dank!

Ich werde mir das morgen mal ansehen, vielen Dank für den Hinweis. Auch Ihre weiteren Fragen haben wir nicht vergessen :slight_smile:.

Hallo Herr Früh,

Sie haben recht, die genannte Stelle funktioniert bei einer Repository-Implementierung nicht wie gewünscht. Und auch die IsRepositoryID-Methode kommt mit mehreren Repository-IDs nicht klar. Sie können sich gerne beim Support melden und eine neue Assembly erhalten. Wenn Sie die Sourcen selber compilieren wollen, reichen die folgenden Änderungen:

internal static bool IsRepositoryID(string value)
{
    // dieser Check ist jetzt weniger scharf, reicht aber völlig aus, ein Dateiname fängt definitiv nicht mit repository:// an
    return value != null && value.StartsWith("repository://", StringComparison.OrdinalIgnoreCase);
}

sowie an der von Ihnen gefundenen Stelle

if (IsRepositoryID(projectFile))
{
    m_Parent.LastProjectFile = projectFile.Split(';')[0];
}

Dann klappt es bei mir auch mit dem Kombinationsdruck. Vielen Dank noch einmal für Ihren Hinweis!

Das hat bei mir funktioniert wie gedacht - ich habe ein Bild in das Repository importiert (mit Hilfe der RepositoryImportUtil-Klasse) und verwende es wie folgt. Im Hintergrund sehen Sie auch das Ergebnis:

Klappt das bei Ihnen so auch?

Die Verwendung von Unterordnern ist nicht vorgesehen, hier könnten Sie je Bericht eine eigene Repository verwenden die das wie gewünscht simuliert, also die Projekte in eigene Repository speichert und nicht eine Repository für alle verwendet.

Ja, das geht bei mir auch.

Ich meinte es noch ein bisschen anders… Wenn ich im Repository-Modus eine Datei über den File-Picker auswählen will, zeigt mit der Designer eine Liste von Bildern aus dem Repository (s. Screenshot). Ich wähle also über den Namen (nicht über die Repository-Item-Id) ein Bild aus. Meine Erwartungshaltung wäre also, dass ich auch über Drawing(“ProgressDoneBg”) irgendwie das Bild “ProgressDoneBg” aus dem Repository auswählen kann. Dass wäre z.B. interessant, wenn man dynamisch auf Basis einer Variable Logo A oder Logo B anzeigen will. Wenn man den Designer-Anwender hier nötigt, die komplette Repository-Item-Id zu hinterlegen, wäre das schon ein wenig unpraktisch. Ich denke, der Designer-Anwender sollte das Konzept einer Repository-Item-Id eigentlich nicht kennen müssen.

Was meinen Sie?

Screenshot: File Picker im Repository-Modus

1 Like

Ja, so eine Idee in diese Richtung hatte ich auch schon… Allerdings vermute ich trotzdem, dass es ein bisschen unübersichtlich werden könnte. Globale Dinge wie Firmenlogo in verschiedenen Farbtiefen und Größen würden wahrscheinlich in jedem Report angeboten werden müssen.

Aber vielleicht sehe ich das auch zu kritisch.

Wir fangen erst einmal an und gucken wie es läuft :wink:

So macht das absolut Sinn - wir schauen uns das einmal an. Natürlich muss hier die Performance im Auge behalten werden, als letzter Fallback bei einem nicht auflösbaren Bildnamen noch einmal im Repository nachzusehen sollte aber durchaus machbar sein.

Wir werden das mit dem kommenden Servicepack von LL26 ermöglichen. Wenn Sie möchten melden Sie sich vorab beim Support um einen Hotfix zu erhalten. Vielen Dank für die Anregung :+1:.