Created attachment 49745 [details] Program to reproduce text field placeholder problem When I load a document with text fields in a hidden window, then get the text fields from the enumeration XTextFieldsSupplier.getTextFields().createEnumeration() via UnoRuntime, the method com.sun.star.text.XTextRange.getString() returns an empty string. Only after some delay this method returns the correct result. The problem does not occur when the window is not hidden. The problem does not occur with OpenOffice.org 3.3.0. I tested this on Windows XP Professional SP3 German. Attached is a sample program and a sample document. It needs ridl.jar, unoil.jar, juh.jar, unoloader.jar, jurt.jar. The program contains hard coded references to LibreOffice or OpenOffice programs and to the document.
Created attachment 49746 [details] sample document template to reproduce problem
Additional information regarding the program OO_LO_Placeholder_Test.java: The main() function starts the LibreOffice or OpenOffice program using startOO_LO_Instance(), loads a document template using loadDocument() and gets all placeholder text fields as an ArrayList<XTextRange> using getPlaceholders(). Then it gets the first XTextRange element and calls getString() in a loop until the result's length is >0. The loop counter shows how many calls were necessary to get the expected result. Instead of the loop a delay of 1 sec somewhere between loading the document and calling XTextRange.getString() makes this method return the correct result. After the loop the program does some sample replacement using replacePlaceholders(). With a visible window or with OpenOffice 3.3.0 the replacement can be done without any delay.
confirming bug, lo3.4.2.rc3 and oo3.4beta1 are affected too. oo 3.2/3,2.1 and oo 3.3 are ok.
Hi, I'm convinced that the problem that LO.org >= 3.3 sometimes return an empty String, is simply one of the symptoms which are produced from a really great Bug. The Bug solely occurs when a Document is opened in hidden state. Funktions like printing or closing the "hidden" document are also affected from this Bug. Jürgen Steinhilber
adding a CallBack-Handler will not solve the problem - with attribute "hidden=true" output is: Document now available as XTextDocument loop 100000 placeholder[0] = Replace placeholder[0] = empty placeholder name !!!!!! ... "hidden=false" works fine ... -- final XRequestCallback xAsyncCallback = AsyncCallback .create(xOfficeComponentContext); xAsyncCallback.addCallback(new ExecuteAsyncron(), this.templateFile); class ExecuteAsyncron implements XCallback { public void notify(final Object sUrl) { try { System.out.println("start Async Job exeute ..."); executeJob((String) sUrl); System.out.println("finished Async Job exeute ..."); try { ooloTests.release(); } catch (Exception e) { e.printStackTrace(); } System.exit(0); } catch (final com.sun.star.io.IOException e) { e.printStackTrace(); } } } void executeJob(final String sUrl) throws com.sun.star.io.IOException { ooloTests.loadDocument(); ... }
if you do a refresh before enumerating the placeholdernames are all identified correctly, but it doesn't solve the real problem private ArrayList<XTextRange> testePlatzhalter(){ if(xTextDocument==null){return null;} ArrayList<XTextRange> arrayList = new ArrayList<XTextRange>(); try { XTextFieldsSupplier xTextFieldsSupplier = (XTextFieldsSupplier)UnoRuntime.queryInterface(XTextFieldsSupplier.class, xTextDocument); XEnumerationAccess xEnumerationAccess = xTextFieldsSupplier.getTextFields(); //do a refresh() and all Placeholdernames can be found while hidden=true XRefreshable refresh = null; refresh = (XRefreshable)UnoRuntime.queryInterface(XRefreshable.class, xTextDocument); refresh.refresh(); //but it doesn't solve the real problem which also occurs //sporadically when printing or closing documents with hidden=true XEnumeration xEnumeration = xEnumerationAccess.createEnumeration(); while(xEnumeration.hasMoreElements()) { Object object = xEnumeration.nextElement(); XTextField xTextField = (XTextField)UnoRuntime.queryInterface(XTextField.class, object); XServiceInfo xInfo = (XServiceInfo)UnoRuntime.queryInterface(XServiceInfo.class, xTextField); XTextRange range = xTextField.getAnchor(); //Placehoders only if(xInfo.supportsService("com.sun.star.text.TextField.JumpEdit") /* || xInfo.supportsService("com.sun.star.text.TextField.User")*/){ arrayList.add(range); } } }catch(Exception exception) { exception.printStackTrace(); } return arrayList; }
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
this is a regression in OOo 3.4, from CWS sw34bf01 (8485708f3001fca132c3353c464fe7187ef62bed), related to fix for issue 112425, issue 85766. in that commit i had changed the expansion of Writer text fields such that they are only actually expanded via the text formatting, and all the other callers of SwField::ExpandField get a cached value, because for many field types some setup is necessary to get a correct value, which only the text formatting does properly. this has introduced a race condition: if the field value is requested before the layout of the document is complete, an empty string may be returned. @Bodo Meissner: can you give a MPL/LGPLv3+ license for your attached template bug document? i'd like to include a unit test for this, and just committing that to our git repo would be easiest :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.03.2012 18:59, schrieb bugzilla-daemon@freedesktop.org: > @Bodo Meissner: > can you give a MPL/LGPLv3+ license for your attached template bug document? > i'd like to include a unit test for this, and just committing > that to our git repo would be easiest :) @Michael Stahl: The original document and test program were created by the main developer of the Thera-PI project (thera-pi.org), Jürgen Steinhilber, with an AGPL license. I modified both document and code to make them better suited for the bug report. So for my changes I can agree to MPL/LGPLv3+ license. I think Jürgen Steinhilber will also agree if it helps fixing the problem in LibreOffice or OpenOffice.org. I added him as CC to get a confirmation. > this has introduced a race condition: if the field value is > requested before the layout of the document is complete, > an empty string may be returned. I think it would be OK if there was a way to check when the layout is complete. The application could wait for an event or poll for something before trying to access the fields. Could a similar problem occur if the layout must be changed when the application has replaced some fields with text? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9RGzAACgkQnMz9fgzDSqeybgCgjS/u4FxHPT5I67e8+qlzVEy5 cKoAmwfUCpUUx9iLOcy/FG5zFaOVBVZB =h/sw -----END PGP SIGNATURE-----
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9519deda120b73b72e75d89c3b2ae3d66220ec2d fdo#39694: SwTxtFld: do expand the field in the ctor
fixed on master bug 42073 is a different regression from the same change. > I think it would be OK if there was a way to check when the layout is complete. that is possible in principle by listening for the "OnLayoutFinished" event at the global event broadcaster, but unfortunately there is a bug (filed somewhere in issuezilla) that this event is not sent for every document, just about 98% of them.
Hallo Herr Stahl, hallo Bodo, natürlich(!) bin ich mit der jeweils erforderlichen Lizenz einverstanden, wobei es mir schleierhaft ist weshalb ein derart kümmerliches "Testprogrämmle" auch noch eine Lizenz braucht, aber ich muß ja auch nicht alles verstehen. Schlußendlich ist es im ureigensten Interesse des Thera-Pi-Projektes, daß die Software auch mit LibreOffice betrieben werden kann. Grüße Jürgen Steinhilber Reutlinger Therapie-& Analysezentrum GmbH Marie-Curie-Str.1 72760 Reutlingen Tel. 07121 9617-20 Fax 07121 9617-22 Internet: http://www.rta.de Am 02.03.2012 20:10, schrieb Bodo Meissner: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 02.03.2012 18:59, schrieb bugzilla-daemon@freedesktop.org: > >> @Bodo Meissner: >> can you give a MPL/LGPLv3+ license for your attached template bug document? >> i'd like to include a unit test for this, and just committing >> that to our git repo would be easiest :) > @Michael Stahl: > The original document and test program were created by the main developer of the Thera-PI project (thera-pi.org), Jürgen Steinhilber, with an AGPL license. I modified both document and code to make them better suited for the bug report. > So for my changes I can agree to MPL/LGPLv3+ license. I think Jürgen Steinhilber will also agree if it helps fixing the problem in LibreOffice or OpenOffice.org. I added him as CC to get a confirmation. > >> this has introduced a race condition: if the field value is >> requested before the layout of the document is complete, >> an empty string may be returned. > I think it would be OK if there was a way to check when the layout is complete. The application could wait for an event or poll for something before trying to access the fields. > > Could a similar problem occur if the layout must be changed when the application has replaced some fields with text? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk9RGzAACgkQnMz9fgzDSqeybgCgjS/u4FxHPT5I67e8+qlzVEy5 > cKoAmwfUCpUUx9iLOcy/FG5zFaOVBVZB > =h/sw > -----END PGP SIGNATURE----- >
Now in -3-5 branch => will be available in 3.5.2 => set target accordingly. http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=81828ab68a37715505b19988cdb4508ee0477c68
thanks Jürgen for the license, your test document (sans the images, to save space) is now here: cgit.freedesktop.org/libreoffice/core/commit/?id=0982257e5902a29c3faf90c0fa3dba809a2462e5 and the unit test: http://cgit.freedesktop.org/libreoffice/core/commit/?id=870e5a8e8251967b513b4255231ee9665b085431 because of the bugzilla outage it wasn't picked up automatically, so: fixed in libreoffice-3-4 as well: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=bad17b39d1567c5f58c439093c8f8b692e106cdc