mir ist ein Fehler im Designer begegnet, welcher leider äußerst störend ist:
Wenn für eine Tabelle eine feste Höhe angelegt wurde und diese aber durch irgendeinen Grund überschritten wird, dann entsteht eine Dauerschleife. Der Designer probiert es pausenlos erneut zu erstellen und man ist gezwungen das Programm mit dem Taskmanager zu killen.
Das ist kein seltenes Vorkommen, sondern bei Bedarf mit 100% Quote replizierbar. Als Nutzer bekommt man allerdings kein Feedback des Programms, wo überhaupt der Fehler liegt. Ergo man sucht bis man letztendlich über Debwin folgendes erfährt:
grundsätzlich ist es schwierig, das Thema “Endlosschleife” zu lösen. Oft entstehen die Schleifen durch die unterschiedlichsten Bereiche und Designer Eingaben / Einstellungen.
Dort ist auch die Möglichkeit aufgeführt, Schleifendurchläufe zu begrenzen. Das würde zumindest das “endlose” umgehen.
Aber ja, ganz ersichtlich ist es nicht, wenn man nicht sofort nach jeder Änderung einmal in die Berichtsvorschau springt um zu sehen, ob sich ein möglicher Fehler eingeschlichen hat. Nimmt man viele Änderungen auf einmal vor, fehlt dem Anwender beim designen möglicherweise der Kontext zur Endlosschleife.
Daher habe ich intern einen Wunsch für unsere Entwicklungsabteilung angelegt, eine Option einzuführen, die es erlaubt, den betroffenen Objektnamen (zum Beispiel die Tabelle), der verantwortlich für die Endlosschleife ist, anzuzeigen.
Das ist genau die Art von Bug, die einen wahnsinnig macht, das kenne ich nur zu gut. Dieser berüchtigte “IDLE COUNTER”, der in Debwin durchdreht, ist meistens ein Zeichen dafür, dass die Rendering-Engine in einer Endlosschleife hängt, weil sie den Seitenumbruch nicht berechnen kann. Im Grunde versucht deine Tabelle, Inhalte in einen gesperrten Bereich zu „drücken“, und da der Layout-Algorithmus keine logische Lösung findet, fängt er immer wieder von vorne an. Das ist typisch für Reporting-Tools mit einer Single-Pass-Engine.
Ein kleiner Experten-Trick, den kaum jemand nutzt, um das ohne Task-Manager zu lösen: Versuch mal, die Eigenschaft “Keep Together” (Zusammenhalten) bei den Gruppen- oder Datenzeilen auf “False” zu setzen. Oft ist genau diese Einschränkung in Kombination mit der festen Höhe der Auslöser für den Konflikt. Wenn die Engine die Zeile aufteilen darf, stoppt die Schleife. In Sachen “Topical Authority” beim Designer-Debugging: Die Zahl hinter dem IDLE COUNTER gibt oft an, wie viele Neupositionierungsversuche vor dem Crash gemacht wurden. Es wäre definitiv menschlicher, eine Fehlermeldung wie “Overflow bei fester Höhe” zu bekommen, statt eines kompletten Freezes!
Also den Idle Counter kannst du ja wie in meinem geteilten Link beschrieben per Option “LL_OPTION_IDLEITERATIONCHECK_MAX_ITERATIONS” bereits setzen.
Bezüglich der konkreten Hinweismeldung / einer Option dies einzublenden, die sich auf das jeweilige Objekt bezieht, habe ich das wie erwähnt als einen Wunsch intern bei unserer Entwicklungsabteilung eröffnet. Ob und wann dies umgesetzt werden würde, kann ich dir allerdings nicht sagen.
Wo genau setze ich denn diese Option, wenn ich einen Report aus C# aufrufe? Muss das in jedem Report einzeln gesetzt werden oder kann das in die Export-Options aufgenommen werden?
LL.Core.LlSetOption(338, 0); sollte für deinen Fall funktionieren, bzw. die “0” (keine Prüfung) dann durch die jeweilige Zahl ersetzen, die man haben möchte.
Funktioniert es mit dieser Weise die Option zu setzen?
probiert, alle Grenzen werden überlaufen, es wirft keinen Error oder stoppt die Versuche sich zu erstellen.
So erstelle ich das ganze:
LL.LicensingInfo = LL_Repository.LizenzInfo;
MemoryStream memStream = new MemoryStream();
LL.DataSource = dt;
ExportConfiguration exconfig = new ExportConfiguration(LlExportTarget.Pdf, memStream, ReportVorlage);
exconfig.ExportOptions.Add(LlExportOption.PdfTitle, filename);
exconfig.ExportOptions.Add(LlExportOption.PdfAuthor, "Firma");
//LL.Core.LlSetOption(LL_OPTION_IDLEITERATIONCHECK_MAX_ITERATIONS, 1);
LL.Core.LlSetOption(338, 90000); //ID 338 steht für die Max-Iteration-Option, 90000 für die Versuche, die ausgeführt werden vor dem abbrechen
//exconfig.ShowResult = false;
// PDFs als Stream exportieren
LL.Export(exconfig);
Die eingetragene Option sieht an sich soweit korrekt aus. 90000 ist natürlich eine sehr große Zahl, aber so wie von dir beschrieben geht es mit kleineren Werten ja auch nicht.
Um jetzt weiteres zu analysieren, wäre es hilfreich, wenn du einen Case bei uns über das Supportportal anlegen könntest: Login/Logout – Reporting Hub
Darüber können wir dann sinnvoll den Weg einer genaueren Analyse gehen, mit Log- und Projektdatei beispielsweise oder auch über eine Reproduktion.
