To reproduce it create new form in LibO3.4RC1 with Form wizard. I tested on win7. - Select table, go to the 5. step "Arrange controls", in earlier versions for example in OOo 3.3 the page background became colored with default color Beige. In LibO3.4 default color not selected, remains white. - In 7th Step "Apply styles" if click on any style, no changes in colors, the background remains white. See same bug in OOo bugtracker 117472, and cws fs34b for solution.
If there is a solution in a CWS, and the CWS is set to a status indicating it is somewhat ready, we might eventually get to it then when trawling through OOo CWSes we could pick up. But still, as one never knows how long OOo CWSes will be accessible, if the fix is small, could you please extract the patch and attach here?
Hi Tor, From the comments on the CWS fs34b page, it appears that the code was integrated into milestone m104 on April 14, 2011. So we should already have it in our own code if we have merged from m106. Or did I miss something ? I found this entry from April 14th, 2011 : http://hg.services.openoffice.org/OOO340/rev/b40134c2cf29 As you can see it is quite big because this CWS addresses several Base issues rather than just the one corresponding to this bug report. Alex
OK, thanks for investigating. Our 3.4(.0) contains OOo changes up to their m103. It was way too complex to integrate their later changes for our 3.4 timetable. We are in the progress of integrating their m104, m105 and m106 changes into our master branch. Once that is done, hopefully important bug fixes, if they can be easily identified and separable, can then be picked from master into the libreoffice-3-4 branch, and thus appear in our 3.4.1. As you say, that CWS changeset contains a lot of stuff, and unfortunately without knowing the code it might be hard to figure out exactly which parts of it fixes this particular bug. (But it sure would help if you could try; maybe there even is some added comment there that mentions "page background"?)
In fact, the whole damn OOO-340 changeset thing zipped up is massive (still downloading and have already reached 200Mb), I'll post just the Base changes that I can see from CWS fs34b here as an attachment. The code also contains comments in German. I will try and clean them up / translate them into English later. Alex
Created attachment 47214 [details] dba subset changeset from OOO340_b40134c2f29
Well, that whole changeset is in my opinion way too much to put in our 3-4 branch. We have no idea whether it even would compile, or whether it depends on other changes in other CWSes.
FWIW, Frank Schoenheit has been working on another CWS, fs35a, which also corrects more bugs in Base. Unfortunately, fs35a is 11Mb. Even zipped up, it weighs in at 2.2Mb, so more than fdo bugzilla will allow, ie. I can not post it here. I guess the only thing for me to do would be to try and put it my git tree and see if it compiles. Alex
*** Bug 38119 has been marked as a duplicate of this bug. ***
*** Bug 42903 has been marked as a duplicate of this bug. ***
*** Bug 43161 has been marked as a duplicate of this bug. ***
The background colours for the db form wizard are CSS style sheets from what I can gather in the source code. The question is : why aren't they being applied ? Alex
Hi Lionel, Assigning task to you. Do you think you could take a look at this ? If not, just unassign yourself. Alex
Fixed in master (3.5). I'm not backporting to 3.4.5, yell if you think it should be the case. All one had to do is read more of OO.org's issue tracker... https://issues.apache.org/ooo/show_bug.cgi?id=117472#c2 says: caused by fix for bug 109943. Fixed in CWS fs34b. And in i#109943 https://issues.apache.org/ooo/show_bug.cgi?id=109943#c8: well, at least one warning did point to a problem, but the fixed introduced another problem :) Consider sPropValue.trim(); if ( sPropValue.indexOf("#") > 0 ) ... which yielded a warning in the first line, which then has been changed to sPropValue = sPropValue.trim(); Unfortunately, this means that a string starting with " #" now is not matched by the second line anymore, while it previously was ... which resulted in bug 117472 :) (Of course the second line is buggy, the proper check needs to be " > -1".) Grepping for sPropValue.trim in the link given in comment 2 shows the 0 -> -1 change indeed, and that works!
Hello (In reply to comment #13) > Fixed in master (3.5). Sorry, It still occurs with windows 7 64 bits and LibreOffice 3.5.3.2 Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80 Regards Pierre-Yves
*** Bug 49329 has been marked as a duplicate of this bug. ***
*** Bug 51191 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > Fixed in master (3.5). I'm not backporting to 3.4.5, yell if you think it > should be the case. > Hi Lionel, Apparently this bug is still present, at least on Windows. I will check on Mac/Linux. Alex
Yes, this bug is back (all platforms). The reason is very simple. This commit: commit b35b7080980c0ba43f411db469feb30f8a5c6881 Author: Michael Meeks <michael.meeks@suse.com> Date: Fri Dec 2 17:15:48 2011 +0000 pywizards: resurrect Xisco's code lost in rebasing Xisco merged this to master and then deleted it on master, which cause these files to get lost during the re-base across that. reverts my fix. From the commit message, I'd expect it to *only* touch/create python files, but it also touches the java wizards. Michael, this is not the only java file touched by this commit; please consider whether we should revert the java parts of this commit or not. Although from a quick glance the other changes to Java files look innocuous / stylistic.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=15fc21e6ca8f461286ca4bc88ebb74beca54213b&g=libreoffice-3-6 fdo#37626: form wizard recognise "#" also at beginning of line It will be available in LibreOffice 3.6.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d39b71f35e088f9e153e2462158ce2962cf3a8a fdo#37626: form wizard recognise "#" also at beginning of line
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca28a2430e392d7a7fe6f636da446095e55c3676&g=libreoffice-3-5 fdo#37626: form wizard recognise "#" also at beginning of line It will be available in LibreOffice 3.5.6.
(In reply to comment #18) > commit b35b7080980c0ba43f411db469feb30f8a5c6881 > Author: Michael Meeks <michael.meeks@suse.com> > Date: Fri Dec 2 17:15:48 2011 +0000 > Michael, this is not the only java file > touched by this commit; please consider whether we should revert the java parts > of this commit or not. Although from a quick glance the other changes to Java > files look innocuous / stylistic. OTOH, they might be related to these warnings: /home/master/src/libreoffice/core/wizards/com/sun/star/wizards/ui/event/MethodInvocation.java:69: warning: non-varargs call of varargs method with inexact argument type for last parameter; cast to java.lang.Class<?> for a varargs call cast to java.lang.Class<?>[] for a non-varargs call and to suppress this warning this(paramClass == null ? obj.getClass().getMethod(methodName, null) : obj.getClass().getMethod(methodName, new Class[] ^ /home/master/src/libreoffice/core/wizards/com/sun/star/wizards/ui/event/MethodInvocation.java:94: warning: non-varargs call of varargs method with inexact argument type for last parameter; cast to java.lang.Object for a varargs call cast to java.lang.Object[] for a non-varargs call and to suppress this warning return mMethod.invoke(mObject, EMPTY_ARRAY); ^ /home/master/src/libreoffice/core/wizards/com/sun/star/wizards/ui/event/DataAware.java:316: warning: non-varargs call of varargs method with inexact argument type for last parameter; cast to java.lang.Object for a varargs call cast to java.lang.Object[] for a non-varargs call and to suppress this warning return getMethod.invoke(target, EMPTY_ARRAY); ^