Seriendruck Menüpunkt Aktiv nur beim ersten offenen Dokument about lots

[chrlutz]

From [email protected] on March 06, 2012 23:39:52

Problematisch ist diese Situation v.a. im Zusammenhang mit Etikettendruck:

• Ich starte Writer (und habe ein "frisches" Dokument: Dokument1)
• Ich starte den Etikettendialog, wähle Etikettenformat ... und beende den Dialog mit "Neues Dokument" (und habe zusätzlich zu Dokument1 ein Etikettendokument: Dokument2)
• Will ich nun in diesem Etikettendokument Etikett1 via Wollmux-Seriendruck mit Seriendruckfeldern befüllen, ist der Menüpunkt inaktiv.

[chrlutz]

From [email protected] on May 03, 2012 00:04:49

Sind in diesem Fall die andern Menübuttons des WollMux (z.B. Extras->Info über Vorlagen und Formulare (WollMux) oder Ziffer einfügen aus der SLV-Leiste) auch deaktiviert oder gehen die?

[chrlutz]

From [email protected] on May 09, 2012 03:44:53

Hallo Christoph,

Ich bin jetzt dazu gekommen die Sache nochmal zu prüfen.

Extras-> Info über Vorlagen... : geht
Ziffer einfügen aus SLV-Leiste: inaktiv (alle Schaltflächen der Symbolleiste)

Hast du schon eine Idee????

[chrlutz]

From [email protected] on June 12, 2012 01:22:44

Ich habe die Ursache aber noch keine Lösung:

Ursache ist, dass LibreOffice offenbar einen (noch nicht genauer untersuchten) Bug in den Methoden UnoRuntime.areSame(this.compo, other.compo) oder UnoRuntime.generateOid(compo) eingebaut haben muss. Jedenfalls kann de.muenchen.allg.itd51.wollmux.HashableComponent eine bereits in einer HashMap abgelegte Uno-Komponente (z.B. ein gerade mit onCreate neu geöffnetes Textdokument) nicht wieder finden. In Folge versagt also die Methode de.muenchen.allg.itd51.wollmux.HashableComponent.equals() und alles was daran hängt - insbesondere die Klasse de.muenchen.allg.itd51.DocumentManager, die eine HashMap als Ablage der Dokumenteninformationen benutzt.

Wird nun das neue Dokument geöffnet, so kann in Folge der de.muenchen.allg.itd51.wollmux.event.GlobalEventListener in der Methode onCreate(compo) die Komponente in das docManager-Objekt aufnehmen, jedoch beim onViewCreated(compo)-Event nicht mehr korrekt aus dem docManager-Objekt auslesen. Der WollMux entscheidet sich daraufhin, die Komponente zu ignorieren.

Es muss also nun der genaue Fehler identifiziert werden, der in LibreOffice dafür sorgt, dass UnoRuntime.areSame(this.compo, other.compo) oder UnoRuntime.generateOid(compo) nicht mehr korrekt funktionieren. Dann muss dieser Fehler gemeldet werden und ein Workaround dafür im WollMux implementiert werden (was ich derzeit aufgrund mangelnder Ressourcen nicht leisten kann).

[chrlutz]

From [email protected] on August 21, 2012 07:47:52

Bei meinem aktuellen LibreOffice 3.5.5.3 unter Windows scheint das Problem nicht mehr aufzutreten. Kann das bitte jemand noch auf einem anderen System bestätigen und das Ticket dann schließen?

[chrlutz]

From [email protected] on August 22, 2012 04:22:16

Hm ...
Habe mir gerade die 3.5.6(.2) installiert; das Verhalten ist noch genauso:

• im ersten Dokument ist der Menüpunkt aktiv.
• öffne ich ein neues Dokument, ist "darin" der Menüpunkt inaktiv (grau)

Schade, hatte mich schon gefreut.

[chrlutz]

From [email protected] on August 22, 2012 05:22:50

Der Fehler ist in 3.6.0.2 auch noch drin.

Status: Accepted

[chrlutz]

From [email protected] on August 24, 2012 05:49:07

Ich habe im LO-Quellcode nachgeschaut, und so weit ich das beurteilen kann, hat sich seit OOo 3.2.1 nichts an der generateOID- oder der areSame-Methode geändert.

[chrlutz]

From [email protected] on August 27, 2012 06:49:44

Nach eingehender Recherche sieht es mir danach aus, dass der Fehler in GlobalEventListener.onViewCreated (Zeile 187) liegt:

if (xTextDoc != null && docInfo != null && isDocumentHidden(compo))
{
  docManager.remove(compo);
  return;
}

Ein neues Dokument ist beim Aufruf von onViewCreated unsichtbar und daher wird es aus dem docManager entfernt und nicht weiter bearbeitet. Das war unter OOo noch nicht so. Da war das Dokument nicht 'hidden'.

[chrlutz]

From [email protected] on August 29, 2012 05:11:43

Ich habe die Stelle in LibreOffice gefunden, die für die Änderung des Veränderung des Verhaltens bei der Abfrage des Properties 'isHidden' verantwortlich ist.

In der Datei ./framework/source/services/frame.cxx wurde in Zeile 2662, der Handler für das Property 'isHidden' für Frames geändert. Das ist genau das Property, dass von der WollMux-Funktion 'isDocumentHidden' abgefragt wird. Nachdem ich das alte Verhalten wieder hergestellt hatte, wird auch der Menüpunkt wieder korrekt angezeigt.

Jetzt muss ich herausfinden, weshalb diese Änderung gemacht wurde.

[chrlutz]

From [email protected] on August 29, 2012 06:17:31

Dieser Patch würde die Änderung wieder rückgängig machen und das alte Verhalten von OOo 3.2.1 wieder herstellen. Das könnte allerdings Seiteneffekte in LO haben, die ich nicht abschätzen kann.

Attachment: issue_14.patch

[chrlutz]

From [email protected] on August 30, 2012 00:06:02

Hallo Mr. Ertsey, great work! This is a link to the GIT-Entry in which the behaviour of the hidden-property has been changed: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=74ffe76476d5b8941454a2acce569737237fc1d7 and the commit-comment was:
"autorecovery: we're hidden when we're hidden, not when our associated model has been loaded hidden"

so it seems that this change something to do with the autorecovery (isn't it that feature that automatically runs on a document after a crash?)... But maybe we can ask Frank Schönheit about the background for the change... (I don't know if he is still working for LibreOffice/ApacheOffice)

[chrlutz]

From [email protected] on August 30, 2012 00:28:34

Soweit ich das aus dem Eintrag verstehe, ist es aus Sicht des frames offenbar falsch, das dahinterliegende model nach der Sichtbarkeit zu befragen. Dann kann es doch sein, dass beim Laden eines Dokuments vergessen wurde, die Hidden-Eigenschaft des Frames (m_bIsHidden) korrekt zu setzen...

Das müssten wir ja als Bug in LibreOffice melden können: wenn ein offensichtlich sichtbarer Frame als unsichtbar gemeldet wird...

Auf der anderen Seite weiß ich nicht, ob der WollMux unbedingt den Frame nach der Sichtbarkeit befragen muss. Wenn es über den MEDIADESCRIPTOR des models auch geht (was uns der patch zeigt), dann wäre das ggf. ein möglicher Workaround im WollMux-Code.

[chrlutz]

From [email protected] on August 30, 2012 02:48:29

Ich habe den oben beschriebenen Workaround umgesetzt und committed. Nach längerem Nachdenken komme ich zu dem Ergebnis, dass das nicht nur einen Workaround darstellt, sondern sogar den Fehler richtig behebt.

Begründung:

Beim (Neu) Erzeugen, Laden, oder Seriendruck werden verschiedene Events von OOo erzeugt. z.B. onCreate, onViewCreated, onLoad, ... Ich würde erwarten, dass spätestens zum Event onLoad ein sichtbarer Frame auch als sichtbar gemeldet wird. Ich erwarte aber NICHT unbedingt, dass der Frame seitens OpenOffice/LO bereits zum onViewCreated-event vollständig korrekt initialisiert ist.

Früher hatten wir im WollMux auch nicht das onViewCreated-Event verwendet, um die Dokumentbearbeitung des WollMux anzustoßen, sondern das (weitaus üblichere) onLoad-Event. Die Verwendung von onViewCreated kommt aus der Anforderung von JavaComm, dass WollMux auch durch JavaComm unsichtbar geöffnete Dokumente verarbeiten soll. Die Verwendung von onViewCreated ist also etwas sehr WollMux-spezielles.

Der Test, ob der Frame des Dokuments unsichtbar/sichtbar ist, ist notwendig, um temporäre Dokumente des OOo-Seriendrucks ausfiltern zu können. Dabei wollte ich aber eigentlich schon seit je her nur prüfen, ob das Dokument (also das Model) unsichtbar geladen wurde (das ist ein Unterschied!). Obiger Patch hat gezeigt, wie man so etwas abfragen kann (was ich bisher noch nicht wusste). Daher ist es sogar richtiger den Mediadescriptor auszuwerten als den Frame zu befragen. Ich habe das im WollMux-Code klargestellt (durch die Umbenennung der Methode isDocumentHidden() -> isDocumentLoadedHidden()).

Ich habe auch die mir gängigen Szearien zum OOo-Seriendruck durchgetestet (Seriendruck über Seriendruck-Assistent, Seriendruck über Datei->Drucken, Seriendruck über den MailMerge-Service) und in allen Fällen werden die temporären Dokumente korrekt durch den WollMux erkannt und ignoriert. Ungewollte Seiteneffekte meiner Änderung im Bereich Seriendruck sind damit also m.E. ausgeschlossen.

Dabei bin ich auch gleich über einen weiteren Bug gestoßen der offenbar mit meiner LO-Version unter Windows auftritt: Ein temporäres Dokument eines über Datei->Drucken angestoßenen OOo-Seriendrucks wurde nicht korrekt erkannt und ignoriert, da das Filenamen-Pattern zur Erkennung der temporären Datei zu restriktiv war. Ich habe das Pattern entsprechend angepasst (sollte eigentlich immer noch restiktiv genug sein).

An alle Tester:

ab morgen müsste es ja einen Nightly-Build mit dem Fix geben...

Status: Fixed