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.
Regression with regard to 3.3.2.
Nominate to 35673 ?
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.
*** 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
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)
> 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-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.
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:
Reopening so that it does not show up as fixed in "most annoying".
Pushed now to libreoffice-3-5:
fixed in libreoffice-3-4:
Thanks a lot!
*** Bug 42733 has been marked as a duplicate of this bug. ***