Opened a database with Version: 4.4.0.0.beta1+ Build ID: a15a538fb191b1851f366716914822411b583c58 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2014-12-03_06:05:11 Locale: de_DE Started the form-wizard to create a form. When reaching "7. Apply styles" there arent shown any colors of the background of the form and of the controls. All leaves blank. Form could be saved as expected, but without colors.
Hi robert, I reproduce with LO 4.5.0.0.alpha0+ Build ID: 736b040cb158308e002d24cee8c33e794b2f59a1 TinderBox: Win-x86@39, Branch:master, Time: 2014-12-01_15:20:47 Locale: fr_FR & Windows 7 Home Premium but not with LO 4.3.4.1 Build ID: bc356b2f991740509f321d70e4512a6a54c5f243 Regards, Jacques
Here are some interesting console logs: [jni_uno bridge error] UNO calling Java method itemStateChanged: non-UNO exception occurred: java.lang.NullPointerException java stack trace: java.lang.NullPointerException at com.sun.star.wizards.form.StyleApplier.setDBControlColors(StyleApplier.java:360) at com.sun.star.wizards.form.StyleApplier.applyDBControlProperties(StyleApplier.java:409) at com.sun.star.wizards.form.StyleApplier.changeLayout(StyleApplier.java:228) Noel: taking a look to git history of wizards/com/sun/star/wizards/form/StyleApplier.java, I thought you might be interested in this one.
I noticed that if you don't change the default value of the form at step 5, the color can be changed in step 7. But above all, the console logs from my previous comment appears as soon as yu change form type at step 5, then it appears again in step 7 each time you try to change the color.
I just noticed this first error console log: java.lang.NullPointerException at com.sun.star.wizards.common.Helper.setUnoPropertyValue(Helper.java:46) at com.sun.star.wizards.form.FormControlArranger.insertDBControl(FormControlArranger.java:628) at com.sun.star.wizards.form.FormControlArranger.positionControls(FormControlArranger.java:351) at com.sun.star.wizards.form.FormDocument$ControlForm.initialize(FormDocument.java:405) at com.sun.star.wizards.form.UIControlArranger$ArrangeButtonList.itemStateChanged(UIControlArranger.java:270) at com.sun.star.wizards.ui.ButtonList.fireItemSelected(ButtonList.java:409) at com.sun.star.wizards.ui.ButtonList.setSelected(ButtonList.java:527) at com.sun.star.wizards.ui.ButtonList.actionPerformed(ButtonList.java:719)
I fixed locally the last error quoted but it doesn't solve the problem. So it must be the first error quoted. I'll give a try.
Lionel: I submitted a patch for review, thought you might be interested in this one: https://gerrit.libreoffice.org/13535
Can reproduce only if field selection (step 1) contains a timestamp field.
(In reply to Lionel Elie Mamane from comment #7) > Can reproduce only if field selection (step 1) contains a timestamp field. But then, I can also reproduce that with 4.3.6.0.0+, so maybe that's a different bug, since Jacques says he can reproduce with master but not with 4.3.4.1! Robert, Jacques, do your reproduction examples include a timestamp field? Could you attach them here?
Lionel: try too to change the default form layout. Indeed, if you don't change the default form layout everything works with LO Debian package 4.3.3 (I must retest but I think that even with timestamp field), see my previous comments with main part of stacktraces. Anyway, I'm building 4.3 sources and so will give a try tomorrow.
(In reply to Julien Nabet from comment #9) > Lionel: try too to change the default form layout. Yes, I saw that in your comment and I am indeed changing the form layout.
Have tested it again with version: 4.4.0.1 Build-ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f Gebietsschema: de_DE The background-styles did appear in this version. So I tested again with version: 4.4.0.0.beta2 Build-ID: be92f32b8f21603a6b7a75dd645f7475bdee519d Gebietsschema: de_DE and a new user-profile vor the dev-version. The background-styles werden't shown. The table hasn't any timestamp-field, only a date-field. Don't know why the bug disappears with LO 4.4.0.1. Should we set this to "Worksforme" or is there anybody who could still reproduce?
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68f65c4c08a8804b9a28b926c2a08cee486b60e9 fdo#87301 don't rely on the shape to get the control It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a983fb0f7c7b94d0771d277777035254acce093f Revert "fdo#87301 don't rely on the shape to get the control" It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I did many fixes in/for the Form wizard. This bug was corrected anyway somewhere in the unknown past...
Thank you Lionel! Unassign myself since the final and right fix is from you :-)
I updated my master sources repo and could verify this one.
*** Bug 49048 has been marked as a duplicate of this bug. ***