LSP-Dateien mit Repository-Modus nutzen

Moin moin,

wir haben bei uns in der Anwendung ein Repository implementiert und halten die Projektdateien in der Datenbank.
Wenn wir nun in den Layout Regions einen anderen Drucker auswählen wird dieser beim Speichern nicht hinterlegt. Ich hätte hier erwartet, dass eine Druckerdefinition angelegt und in der Datenbank gespeichert wird.

Im Beispielprojekt “.NET 6\WinForms\Designer Extension Sample” wird die Druckerdefinition wie erwartet auf der Platte gespeichert (hier wird kein Repository verwendet).

Wenn ich das Projekt “MVC Web Reporting Sample” teste wird der ausgewählte Drucker nicht gespeichert.

Wie bekomen wir es hin, dass die Druckerdefinition hinterlegt wird?

Laut Doku sollten die Daten im Stream gespeichert werden. Alternativ wird auf
LL.Core.LlSetPrinterDefaultsDir() verwiesen. Der Ordner bleibt bei Nutzung des Repositorys auch leer.

Beste Grüße

Moin moin Stephan, und herzlich willkommen in unserem Forum!

Vermutlich wird hier der “alte” Web Designer verwendet. Dieser bekommt nichts von den Druckern auf dem Server mit. Die Drucker auf dem Client spielen hinterher beim Druck auf dem Server auch keine Rolle. Wir empfehlen hier, unseren aktuellen Web Report Designer zu nutzen, der Zugriff auf die Drucker auf dem Server hat.

Genau wir benutzen den Web Designer. Dieser wird aber auf dem Server ausgeführt der später auch für den Druck verantwortlich ist, um Zugriff auf die tatsächlich verwendeten Drucker zu haben.

Der Benutzer stößt dann nur noch über unsere Anwendung den Druck oder einen PDF-Export an.

Beim Aufruf von Print() übergeben wir dann den Drucker noch ein mal explizit, aber beim Aufruf von Export ist dies nicht möglich und der Standarddrucker vom System wird gewählt welcher dann für ein anderes Layout sorgt.

Hi Stephan, Vorschlag Idee, du verwendest ImportPrinterConfig zum importieren einer P-Datei.
Könnte so ausschauen (ich hab mal das CreateOrUpdateItem genommen, kannst auch wo anders machen)

public void CreateOrUpdateItem(RepositoryItem item, string userImportData, Stream sourceStream)
        {

            ListLabel LL = new ListLabel();
            FileStream fs = new FileStream("c:\\temp\\test.lsp", FileMode.Create);
            PrinterSettings ps = new PrinterSettings();
            ps.PrinterName = "Microsoft Print to PDF";

            LL.Core.LlSetPrinterInPrinterStream(LlProject.List, ps, fs);

            RepositoryImportUtil importUtil = new RepositoryImportUtil(this);
            importUtil.ImportPrinterConfigFile(this._ll, "c:\\temp\\test.lsp", item.InternalID, userImportData);

Da die Methode eine LL benötigt müsstest du deiner Repository einfach eine LL als Member mitgeben usw.

Was machst du hier?
Du erstellst eine PrinterSettings, machst deine Einstellungen, erstellst deine P-Datei mit dem FS und importierst diese dann in deine Repo mit der zugehörigen InternalId (also von dem Projekt zu dem es gehören soll), einmal importiert, brauchst es nicht mehr importieren das RepoItem hat dann den Typ ‘ll/printerconfig’

sorry für die schnelle Beschreibung keine Zeit gerade, wenn Fragen hast gerne.
LG Erdal

1 Like

Hi Erdal,
leider bekomme ich bei meinen Tests noch den Fehler, dass ich die Printer Config nicht importieren kann weil sie nicht auf ein noch nicht vorhandenes Item verweisen kann.

CXLL27  : 15:43:17.122 00026e1c/06 8 [L02 API]:   >LlRepositoryCreateItemFromFile(5,000001A69ED4FF18,'repository://{E32D33BA-B97E-478C-87B0-CD985B18E0DC}','repository://{42E19284-C662-4486-B084-7C729EB3BA1D}','ll/printerconfig','C:\WINDOWS\TEMP\tmpEA4C.tmp',(NULL))
CXLL27  : 15:43:17.122 00026e1c/06 9 [L04 API]:    item 'repository://{E32D33BA-B97E-478C-87B0-CD985B18E0DC}' cannot be dependent on a parent ('repository://{42E19284-C662-4486-B084-7C729EB3BA1D}') that is not yet in the repository

Die Datei ist in unserem Repository aber zu finden…

Dumme Frage, hast du sichergestellt das es wirklich auch die gleiche Repository ist usw.?
Also die verwendete LL Instanz muss auf die gleiche Repo haben, wie sowas hier z.B.

                using (var util = new RepositoryImportUtil(this))
                {
                    using (var ll = new ListLabel(){FileRepository = this})
                    {
                        util.ImportPrinterConfigFile(ll, pFilePath, item.InternalID);
                    }
                }

Ich hatte natürlich vergessen das FileRepository zu setzen.

Leider laufe ich weiterhin auf Probleme.

Wenn ich das FileRepository gesetzt habe, dann schreibt LL beim Aufruf von LL.Core.LlSetPrinterInPrinterStream(LlProject.List, ps, fs); schon direkt ins Repository und vergibt keine RepositoryId sondern schreibt einen temporären Dateinamen.
Der Aufruf von importUtil.ImportPrinterConfigFile(this._ll, "c:\\temp\\test.lsp", item.InternalID, userImportData); läuft dafür sauber durch aber schreibt keinen Dateiinhalt ins Repository.
Mal schauen ob das ein Problem ist das in einer neueren Version behoben ist.

Hallo Stephan, ich kann mir das später heute Abend gerne nochmal in Ruhe anschauen wenn dir das hilft, würde dann meine Erkenntnisse mit dir teilen :wink:

Hi Erdal,

erstmal vielen Dank, dass du dir so viel Zeit nimmst das zu erklären und zu testen.

Bis jetzt bin ich von der Lösung noch nicht beeindruckt.

Ein Update auf LL 29 hat keine Veränderung im beobachteten Verhalten gebracht.
Ich hab jetzt manuell die Daten in den korrekten Repositoryeintrag kopiert. Dann bekomme ich nach dem Öffnen auch den gespeicherten Drucker angezeigt. Änderungen an der Druckerauswahl werden aber nicht zurück ins repository geschrieben.
So langsam beschleicht mich das Gefühl, dass die P-Dateien nur leidlich mit dem Repository zusammen funktionieren.

Es ist tatsächlich so wie @oboyaci oben schrieb - normalerweise wird der Web Designer nicht auf dem Server ausgeführt, daher werden die Druckerkonfigurationsdateien absichtlich nicht geschrieben. Das liegt aber nicht am Repository sondern war eine bewusste Entscheidung bei der Entwicklung des Web Designers, die häufig Sinn ergibt :slight_smile:.

Ich verstehe, dass das hier jetzt hinderlich ist. Der beste Workaround wäre tatsächlich, den browserbasierten Web Report Designer zu verwenden, der hat diese Einschränkung nicht, da das Backend immer auf dem Server läuft.