Ladezeit beim erstmaligen Aufruf des Printer > 30sec

Deutschsprachiges Forum
#1

Hallo Zusammen,
ich weiß, das gibt es nicht, aber seit gestern benötigt der Aufruf des Printers mit

hProjectTyp = LlProject.List;
bool askProjectFile = false;
LL.Print(hProjectTyp, printFile, false);

(Printfile ist “C:\EventCompany\PrintTemplates\Gehalt\Test.lst”)

beim ersten Mal mehr als 30 sec. (Ab dem zweiten Mal schnell wie immer)
Davor (seit mehreren Monaten) war er sofort da (das Auswahlfenster)

Ich erstelle den Drucker in den GlobalConfig über

public static ListLabel PrintLL = new ListLabel();

und weise diesen dann in dem Modul über

ListLabel LL = GlobalConfig.PrintLL;

zu.
Die Verzögerung tritt seit heute morgen auf und ich habe keine Ahnung, woran es liegen könnte.
Ich habe versucht:

  • Upgrade auf VisualStudio 2022
  • Installation Servicepack LL27 (Version 27.2)

Als Pakete habe ich installiert (über NuGet)
combit.ListLabel27 (27.2.0)
combit.ListLabel27.Wpf (27.2.0)

Umgebung .net Core 3.1

Ich stehe wie ein Ochse vor dem Berg und habe nichts mehr, was ich noch versuchen könnte. Hat jemand von Euch eine Idee?

Vielen Dank

Niko

#2

Hallo Niko,

wenn das Verhalten erst kürzlich auftritt (seit heute morgen und gestern ging es noch prima rasend schnell?), dann vermute ich diese drei möglichen Dinge:
a) Windows Update
b) Standarddrucker unter Windows ist nun plötzlich ein Netzwerkdrucker oder sowas der nur schwer zu erreichen ist?
c) Manchmal stell Windows auch um, dass es die Standarddrucker im System selber verwalten will - kann man glaube ich aber in den Systemeinstellungen abschalten

In diese Richtung würde ich zuerst mal schauen. Sonst würde ich mal noch zwei folgende Punkte in Richtung List & Label sicherstellen:
a) Egal wann und wo: immer einen List & Label Schutzjob für die Anwendung definieren. War mal vor langem ein Tipp vom combit Support und seither haben wir einiges an Performance rausholen können beim Drucken/Exportieren. Einfach ein List & Label Objekt zentral in der Anwendung anlegen - vielleicht direkt beim Starten der Anwendung:
ListLabel protectLLJob = new ListLabel();

Und wenn die Anwendung zum Schluss dann beendet wird, diesen Schutzjob auch wieder freigeben: protectLLJob.Dispose();

Sonst macht dieses Objekt überhaupt nichts in der Anwendung - kein Druck, kein Export und auch kein Design etc. Und wenn der Designer aufgerufen werden soll oder gedruckt oder exportiert wird, wird immer ein ganz frisches Objekt dafür verwendet:

using(ListLabel workerLLJob = new ListLabel())
{
// ...
}

Damit werden in List & Label intern wohl schon diverse Ressourcen etc. vorgeladen und nochmalige Objekte können diese dann deutlich schneller (sind ja schon geladen) und bequem verwenden.

b) Schau sonst doch auch mal noch im Logfile von Debwin4 nach, was da genau so lange dauern könnte - also wo genau im Logfile geht denn die ganze Zeit verloren? 30 Sekunden klingen ggf. nach einem Standard Netzwerk-Timeout, wenn etwas nicht erreicht werden kann (hier eben ggf. der neue/alte Netzwerkdrucker?)

Hoffe da ist ein wenig was hilfreiches dabei.

Grüße und Erfolg,
Oliver

#3

Super vielen Dank für die ausführliche Antwort, das mit dem Netzwerkdrucker klingt viel versprechend.
Ich schau gleich danach

#4

Das wars !!! Er hat sich irgendeinen komischen Drucker gegriffen.
Den habe ich entfernt und “schon” läuft es wie am Schnürchen

  • hat nur 5 h gedauert, aber jetzt habe ich wenigstens alle Updates gemacht :wink:

Vielen Dank für die Hilfe - you made my evening

Niko

2 Likes

© combit GmbH