Created attachment 46488 [details] database file with form Database forms that were created in a former LibreOffice version look different when opened in LibO 3.4 beta4. Controls are now partially placed outside the form area. Just open attached example using LibO 3.3 and 3.4 (or see screenshots). The biblio exaple connects tot he default biblio db.
Created attachment 46489 [details] Form in Libo 3.3
Created attachment 46490 [details] same form in LibO 3.4beta4
Confirming on Mac OSX. I have seen this problem before in a previous version of OOo (possibly in the change from 2.x > 3.x ??, don't remember exactly). PITA. Alex
Regression with regard to 3.3.2. Alex
Nominate to 35673 ? Alex
This is same as in OOo 3.4 beta, print/web layout problem in edit mode, see OOo bug 117545.
*** Bug 41172 has been marked as a duplicate of this bug. ***
There have been at least 2 reports on the English users mailing list as well regarding this problem, and I have seen at least one on the French users mailing list. Alex
*** Bug 41161 has been marked as a duplicate of this bug. ***
[Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", still a problem with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]" With the newly only available form view "Printlayout" Forms created with LibO 3.3,. "WEB-View" is no longer available, both menu items in menu View are disabled. When I add icons "Weblayout" and "Printlayout" to a new toolbar they will be disabled, too (not unexpectedly) I doubt that that has been intended. OOo 3.3 does not show that problem @Noel: I saw you active in some UI bugs looking similar to me. Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
(In reply to comment #10) [...] > @Noel: > I saw you active in some UI bugs looking similar to me. > Please feel free to reassign (or reset Assignee to default) if it’s not your > area or if provided information is not sufficient. Please set Status to > ASSIGNED if you accept this Bug. well I don't really know anything about form and/or odb layout stuff. For the toolbar entries isn't this a separate problem that deserves it's own issue ( or perhaps I misunderstood the descriptions above )
I volunteer as a tester for base. To prevent this from happening again. This problem indeed occurred earlier in OO, when going from 3.2 to 3.3. Libo 3.4.3 is now standard with Ubuntu but still with this bug. This is quite annoying. I offer clients to replace MS-Access with Libo Base. Clients (only 2 now) wait with migrating to new versions of LiBo and OO until I give the green light because of this experience. Also the form-image embedded in the odt file looks bad. I really would like to help making this better since a well working MS-Access replacement is a potential MS-Office killer.
LibreOffice 3.4.4 opens a database form always in print layout view instead in the Web layout view. But it does work in OOo.
*** Bug 41075 has been marked as a duplicate of this bug. ***
*** Bug 44093 has been marked as a duplicate of this bug. ***
looks like there are 2 problems here: - form doesn't open in web mode this is fixed by the patch attached at issue 117545, which is already in libreoffice-3-5 and master. - the form area is smaller: in OOo 3.3 the height is about 25 cm, while in OOo 3.4 beta and LO 3.4+ it is only ~20cm
Well, the print view vs web view problem is still there in 3.5 RC1. Found a workaround: Open a writer document window Switch to Web view Close the writer document window (no need to save anything) From here out the problem is gone with any Base forms for the duration of the current LibO session.
the form opens in Web layout when it is edited, but if you use "open" i'm not sure because it's not displayed in the menu. the code in dbaccess only requests the Web layout for editing; it doesn't do anything special for open. do you think that "open" should also use the Web layout? actually i just set a breakpoint in SwRootFrm::CheckViewLayout, which is hit several times during opening the document, and always the BROWSE_MODE is set, so that seems to work. about the page size problem: the forms/Obj11/styles.xml has this: <style:page-layout style:name="Mpm1"> <style:page-layout-properties fo:page-width="29.7cm" fo:page-height="21.001cm" apparently OOo 3.4 now uses the page size of the page style even in Web layout, while OOo 3.3 did not. the workaround is simply to set a larger page size via Format->Page. i'm not familiar with this forms stuff: is it wrong to respect the page size for forms?
Should 'open' use web view - YES Should a form respect the page size - NO if in web view, yes if in print view Another good example of how this affects: Use the form wizard to create a form in any layout other then table control, with more then a few fields. The wizard lays it out in web view, but then switches to print view - in most cases this will cram those controls that fall past the right margin over top of other contols (and labels)..it's a real mess.
Until this issue is resolved I can not advice users to go from to 3.3 to 3.5. As I had to advice to stay on 3.3 when 3.4 was released. Drew Jensen is 100% right in the last comments. A pity because 3.5.0rc2 resolved a lot of other issues. odt files with webview=true (embedded on odb or not) should open in webview and in there (own) last saved size. Not in the size of any last saved document.
(In reply to comment #20) Yes, it is one of the few remaining Base blockers in the 3.4 line and still present in the 3.5 line. I will add it to the 3.5 blockers as well. Alex
Added to 3.5 Most Annoying bugs
i think i've tracked down the second problem now. while SwDoc thinks it's in web layout mode, the view actually thinks it's in print layout mode (as seen by setting a breakpoint in SwPageFrm::SwPageFrm). the reason for that is that there is some obscure mbLoaded flag at the SwDoc, and that is not set because we hit a condition in SwDoc::SetAllUniqueFlyNames() that prevents it. there is a new check for the flag in SwView::SwView that connects this flag with the web layout mode/BROWSE_MODE, whose purpose is completely unclear to me. this came in with ebc5777548dea42ed966a16c66d879b1485bbfb4, first commit from CWS swlayoutrefactoring.
fixed on master: 9d32497c01475f2b5e5bec756e4dd0ca9f9d4928
Reopening so that it does not show up as fixed in "most annoying".
Pushed now to libreoffice-3-5: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=994978f537ed61c3aa9ca2ae6b16bb35407ae32c
fixed in libreoffice-3-4: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=7fcb1bb88d0809c64ac4be2aa95a96a883e55af8 http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=fe3ddc22e24a6815481c16e17cd1050bd91b5fe2
Thanks a lot!
*** Bug 42733 has been marked as a duplicate of this bug. ***