+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

Liste mit DOM verändern ohne Speichern


(Guest) #1

Sehr geehrte Damen und Herren

Wir möchten unseren Benutzern die Möglichkeit geben, vor dem Ausdruck noch Änderungen am Layout der Liste vorzunehmen(zb. Spalten ein/ausblenden) Ist es irgendwie mögliche ein Dom Objekt aus dem Speicher an die Print-Engine zu übergeben OHNE dies als Datei zu speichern? So wie wir das sehen, ist dies aktuell nur über ein File möglich. Könne man die Print() und Design() Methoden so überladen, dass anstatt eines Datei-Pfades zb. ein Stream oder eine ListLabelDomProjectList Instanz entgegen genommen werden könnte?

Freundliche Grüsse,
Reto Steimen


(Guest) #2

Wir möchten unseren Benutzern die Möglichkeit geben, vor dem Ausdruck noch
Änderungen am Layout der Liste vorzunehmen(zb. Spalten ein/ausblenden) Ist
es irgendwie mögliche ein Dom Objekt aus dem Speicher an die Print-Engine
zu übergeben OHNE dies als Datei zu speichern? So wie wir das sehen, ist
dies aktuell nur über ein File möglich. Könne man die Print() und Design()
Methoden so überladen, dass anstatt eines Datei-Pfades zb. ein Stream oder
eine ListLabelDomProjectList Instanz entgegen genommen werden könnte?

Ganz ohne File geht es m.E. nicht, aber Sie koennen mit der
“GetFromParent()”-Methode von ListLabelDomProjectBase das aktuell gerade im
Speicher befindliche Projekt (also z.B. nach LlPrintStart) abgreifen und
dann im Speicher manipulieren. Insofern koennten Sie das “Basistemplate”
ausliefern und dann vor der eigentlichen Ausgabe im Speicher aendern.

G.


(Guest) #3

Merci für die schnelle Antwort.
Der Ansatz tönt ganz gut, er könnte unsere Anforderung lösen. Beim Implementieren sind wir jedoch auf das Problem gestossen, dass beim Aufruf von LLPrintStart die Exception “Die Datenbankstruktur, die für das Design verwendet wurde stimmt nicht mit der zur Druckzeit überein.” geworfen wird. Wenn wir anstatt LLPrintStart das Layout mit LL.Print(…) öffnen, startet LL14 ohne Probleme. Ist dieses Verhalten jem. bekannt, bzw weiss was unser Fehler sein könnte?

Merci & Gruess

Wir möchten unseren Benutzern die Möglichkeit geben, vor dem Ausdruck noch
Änderungen am Layout der Liste vorzunehmen(zb. Spalten ein/ausblenden) Ist
es irgendwie mögliche ein Dom Objekt aus dem Speicher an die Print-Engine
zu übergeben OHNE dies als Datei zu speichern? So wie wir das sehen, ist
dies aktuell nur über ein File möglich. Könne man die Print() und Design()
Methoden so überladen, dass anstatt eines Datei-Pfades zb. ein Stream oder
eine ListLabelDomProjectList Instanz entgegen genommen werden könnte?

Ganz ohne File geht es m.E. nicht, aber Sie koennen mit der
“GetFromParent()”-Methode von ListLabelDomProjectBase das aktuell gerade im
Speicher befindliche Projekt (also z.B. nach LlPrintStart) abgreifen und
dann im Speicher manipulieren. Insofern koennten Sie das “Basistemplate”
ausliefern und dann vor der eigentlichen Ausgabe im Speicher aendern.

G.


(Guest) #4

“Reto Steimen” <steimen.r@r…> schrieb im Newsbeitrag
news:26369123200985018@combit.net

Der Ansatz tönt ganz gut, er könnte unsere Anforderung lösen. Beim
Implementieren sind wir jedoch auf das Problem gestossen, dass beim Aufruf
von LLPrintStart die Exception “Die Datenbankstruktur, die für das Design
verwendet wurde stimmt nicht mit der zur Druckzeit überein.” geworfen
wird. Wenn wir anstatt LLPrintStart das Layout mit LL.Print(…) öffnen,
startet LL14 ohne Probleme. Ist dieses Verhalten jem. bekannt, bzw weiss
was unser Fehler sein könnte?

Das meinte ich bildlich :-)). LlPrintStart() sollte nicht direkt aufgerufen
werden, das macht die Komponente schon automatisch wenn Print() verwendet
wird, stattdessen beim Databinding einen Event fuer den Eingriff verwenden -
anbieten wuerde sich m.E. der AutoDefineNewPage-Event, wenn er das erste mal
mit IsDesignMode=False ausgeloest wird.

G.


(Guest) #5

Hmm okee, hab zwar das bildliche nicht richtig intrepretiert, dafür funktioniert Ihre Lösung:)

Besten Dank & Gruess

“Reto Steimen” <steimen.r@r…> schrieb im Newsbeitrag
news:26369123200985018@combit.net

Der Ansatz tönt ganz gut, er könnte unsere Anforderung lösen. Beim
Implementieren sind wir jedoch auf das Problem gestossen, dass beim Aufruf
von LLPrintStart die Exception “Die Datenbankstruktur, die für das Design
verwendet wurde stimmt nicht mit der zur Druckzeit überein.” geworfen
wird. Wenn wir anstatt LLPrintStart das Layout mit LL.Print(…) öffnen,
startet LL14 ohne Probleme. Ist dieses Verhalten jem. bekannt, bzw weiss
was unser Fehler sein könnte?

Das meinte ich bildlich :-)). LlPrintStart() sollte nicht direkt aufgerufen
werden, das macht die Komponente schon automatisch wenn Print() verwendet
wird, stattdessen beim Databinding einen Event fuer den Eingriff verwenden -
anbieten wuerde sich m.E. der AutoDefineNewPage-Event, wenn er das erste mal
mit IsDesignMode=False ausgeloest wird.

G.