Hallo an alle,
ich habe die Probleme die im Zusammenhang mit OO.org und LO.org bestehen eingrenzen können.
Betriebssysteme WinXP und Win7, jeweils mit dem selben Ergebnis.
Wird ein Dokument mit setHidden(true) geöffnet kommt es sowohl beim Drucken im Hintergrund als auch bei der Ersetzung von Platzhaltern (vermutlich noch an einigen anderen Stellen auch) zu Abstürzen und im besten Fall nur zu Fehlverhalten. Das Fehlverhalten drückt sich z.B. so aus, daß der Aufruf
ITextField placeholders = textFieldService.getPlaceholderFields();
zwar die korrekte Anzahl Platzhalter im Dokument erkenn, aber nicht alle Platzhalternamen auslesen kann.

Werden die Dokumente mit setHidden(false) geöffnet oder aber mit setHidden(true) und danach kurz hintereinander die Aufrufe getätigt:
textDocument.getFrame().getXFrame().getContainerWindow().setVisible(true);
textDocument.getFrame().getXFrame().getContainerWindow().setVisible(false);

dann läuft alles fehlerfrei und wie geschmiert.
Ehrlich gesagt glaub ich langsam nicht mehr daran daß das ein Problem von NOA ist. Ich habe das Ersetzen der Platzhalter testweise komplett Über die UNO-API abgewickelt, Ergebnis: das selbe Fehlverhalten.

Irgendjemand eine Idee?
Gruß
Jürgen Steinhilber

Ergänzung:
Beim Versuch die Platzhalter zu ersetzen wird u.a. diese Exception geworfen. com.sun.star.lib.uno.environments.remote.Job befundet sich wohl in der jurt.jar.
Gruß
Jürgen Steinhilber

com.sun.star.uno.RuntimeException:
at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedEx
ception(Job.java:187)
at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:153)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java
:349)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java
:31
at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThr
eadPool.java:106)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendReque
st(java_remote_bridge.java:657)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request
(ProxyFactory.java:159)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(
ProxyFactory.java:141)

Having similar problems here when using NOA and search/replace fields in a document.

Works fine on Linux, but in Windows we intermittently get:
ag.ion.bion.officelayer.text.TextException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge@dca5b7 is disposed

Did you manage to solve your issue?

Hi all,
now after a lot of testings, i'm nearly conviced that the actual Problems NOA with LO-3.4.x and in parts NOA with OO-3.3 are not problems on NOA side.
All the trouble occurs only if a document ist opened in hidden mode. And the thrown exceptions are all pointing to classes btw. methods which are included in the jurt.jar

So i think we first schould contact the developer of LO and OO. btw. the developer of the additional jars.
Where is the source of jurt.jar, juh.jar etc. ?

Btw the latest sourceversion of Markus was definitly version 2.2.4. So if we plan to continue developing NOA, i think it would be very helpful to get this version first.

Jürgen Steinhilber

Hi

We did a little debugging on Libre and we're able to see it crash when trying to perform some of our functions.

When connecting from java you see very little, other than losing your connection - so we had to implement some really horrible "try again" code - which is not nice at all.

Building Libre for debugging on Windows however is no easy task and so this has slowed down our work.

Further development on NOA would be helpful -to incorporate some of this "try again" approach - and also to perhaps suggest patches to Libre.

I have not been able to locate the source repository for NOA - so not sure how to get 2.2.4?

Regards

Ich habe es nun endlich geschafft mittels NOA und LibreOffice (3.4.1) im Hidden-Modus Platzhalter auslesen und ersetzen, drucken, und all die anderen Operationen die für uns notwendig sind - fehlerfrei durchzuführen.
Das Ganze läuft nur dann wenn gezielte "Thread.sleep's" eingebaut werden, was soviel bedeutet wie: mehr als ein vorläufiger Workaround kann das wohl nicht sein.
Das eigentliche Problem muß von den LO.org-Leuten angegangen werden.
Wer Interesse an der modifizierten ag.ion.noa_2.2.3.jar hat kann sich gerne bei mir per Mail melden.

Grüße an die NOA-Gemeinde und ganz besonders herzliche Grüße an Markus, sollte er hier mitlesen.

Jürgen Steinhilber

Hallo,

Sollten wir nicht NOA zu Googlecode ziehen wenn das hier nicht mehr gepflegt wird? Ich wäre gerne bereit ein Repository aufzusetzen und auch an der Weiterentwicklung mit zu arbeiten.

Beste Grüße aus Luxemburg,

Andreas

Das wäre sehr schön!

Hallo zusammen,

ich habe einige Test mit NOA 2.2.5, OpenOffice.org 3.3.0 auf MacOSX Lion gemacht.

Bei mir treten keine Problem mit der Verwendung von Platzhaltern auf. Sowohl im Hidden, als auch auch im Default Modus werden sie sauber erkannt und ersetzt.

Gibt es bei jemanden noch diese Probleme?

Viele Grüße,
Erik