It is tricky to set a static width and height for a form, which is necessary to have a consistent relationship between data fields and a background image (like a picture of a document that provides visual cues). The properties of the form background should be handled in the properties/control dialog box, and there should be a setting for width and height of the form. (not just printer settings). Would be more intuitive, provide more control. Presently, to ensure static sizing, need to put elements on edge of form to make sure it does not shrink. Desired functionality: height and width for form in control dialog box.
@Lionel - another one if you can just confirm that this is a valid request and mark as NEW. Much appreciated
Menu View / Print Layout, and set the desired size in Menu Format / Page.
(In reply to comment #2) > Menu View / Print Layout, and set the desired size in Menu Format / Page. That is another workaround, in addition to the one noted in the enhancement request. It would be *better* if the web view, which is the default view, also provided the user with the option to set the form size. It also is not intuitive that there would a "print" view for a data form interface, when the report interface is what is meant to be printed.
Request enhancement to fix unstable form size functionality. Present functionality is not mature, not reliable. The present form settings create the following problems: 1. Forms do not reliably save either in "Web" or "Print" view, so frequently find myself backtracking to check what mode saved in, re-saving, not even clear if the view type actually is saved in a form -- might be client or transient option so if opened on another computer or at another time, inconsistent user experience. 2. Page size functionality presently fails every so often when quickly opening forms in sequence (I think), in a way that although the window is the right size and the full area is visible, individual controls are pushed to the putative page boundary in clumps (assuming the page boundary -- maybe accidentally taken from another form -- is smaller that viewable area); on close and reopen, problem usually resolves but not clear what would happen if form was re-saved in that condition. 3. As noted in the bug report, Forms are not really supposed to be "Printed" -- that is what Reports are for, so it is not intuitive that there would be a "Print" view for the object. 4. Have found on some forms, when the form is completely displayed in window, if toolbar is activated from docked size of window and moved into view, the control will shift in position as a result of change in visible area, lessen view area if saved. This is not ideal, form size should be static. 5. "Web" view size should not depend on how big the window was last time you edited the form. Too easy to inadvertently hide controls, time consuming to check and recheck that windows were right size during last save so that if opened in "Web" view, will provide adequate user experience. The size of a form is a core function and it should be more reliable.
never confirmed by QA - moving to UNCONFIRMED.
@Doug - if there is a bug in the form layout, please identify this clearly with a reproducible example. If the problem is setting the page width and height, Lionel has already indicated how to do that. If doing it that way leads to the page size not being respected on re-opening, window resizing, etc, please open a separate report for that. At the moment, I fail to see what the problem is, other than some vague dissatisfaction with how things work at the moment.
As noted this is RFE although I do have intermittent bug-like problems that center on this functionality. 1. Lionel's solution appears not to create permanent setting specific to particular form. That is, if there are several forms, several users, and maybe several forms open at once, "Print"/"Web" setting value may toggle or migrate from one form to another without user input. That is, a form that is set for "print" view will go go to "web" view without any clear user direction. The form then will display incorrectly, sometimes in non-obvious ways and require user intervention. Problem is intermittent, specific sequence to trigger is unknown. 2. Base sometimes gets confused along the lines of the separate "Print" width setting, and reorganizes the display of objects on a form along the boundaries in that setting even when displaying in "Web" view, or maybe vice-versa. The settings seem dynamic in some way. The result is that if there is a group of controls on a form, the columns beyond the right-side boundary may be compressed left and crowded/stacked. Likewise, the rows below may be compressed/stacked above. Form in that condition is unusable, appears broken. Self-resolves after closing or reopening either the form or Base entirely, sometimes a few times. I believe the spontaneous reorganization of the controls on the form is along the "Print" boundary when in "Web" mode, but it also could be along boundaries of another form open at same time. Problem is intermittent, one out of say, a hundred times opening form, specific steps to re-recreate are unknown. FWIW, other consumer database solution has setting as I describe; different structure of Base is unintuitive.
(In reply to Doug from comment #7) > As noted this is RFE although I do have intermittent bug-like problems that > center on this functionality. So I see two parts here: 1) A request to improve the interface 2) Some hard-to-reproduce bugs (?) that are related I'm going to toss this one over to the UX Team to review. Perhaps we can separate-out parts (1) and (2), or at least make some progress on the parts that are actionable. Component -> ux-advise Status -> NEW
Adding self to CC if not already on
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Sounds to me like a request for making forms non-resizable. Although this ticket is quite old, please provide a step-by-step description for Base noobs.
(In reply to Heiko Tietze from comment #11) > Sounds to me like a request for making forms non-resizable. Although this > ticket is quite old, please provide a step-by-step description for Base > noobs. No it isn't about requesting non-resizable forms. The request is about allowing the user to specify height and width of a form in the form's properties and having those attributes respected the next time the form is opened. The Print View was no doubt left in because people wanted to be able to print a form off and stick it say, in a folder. In office environments, say, with client folders, this was a fairly common occurrence. It is much quicker and simpler than creating a report based on a query limited to one client and then executing and printing that report. Bear in mind also that the initial report generator in OOo was a pretty rudimentary and underdeveloped tool (more's the pity), so people tended not to use it to print out a single page, instead using the Print View of the form to do so. Unfortunately, as Doug has mentioned, there are stability problems with the display of form control positions from time to time and throughout the various iterations of LibreOffice (and Star/OpenOffice.org before it). Currently, the default behaviour when a new form is created is to use the default page size set at the application level. This can be altered by the user in form design mode by setting the Print (Normal) View display of the form to a desired page size. The previous longstanding solution (during old StarOffice/OpenOffice.org period) was to advise people to use dialogs (via the Macro IDE) instead of forms for which aspect ratios can be precisely defined and were respected. However, using dialogs designed via the Macro IDE brings its own set of problems with it, as they need to be associated with a document in every case, or else instantiated via a macro on loading the ODB file. As such, they couldn't be listed in the list of forms stored within the OBD file either, so it was a kind of all or nothing approach, or some half-baked solution relying on a document that again had its own Print (or Normal) View definition. My thinking from a UI perspective would be to allow such attributes to be set as Height/Width in the Form Properties dialog under the "General" tab and saved in the ODB file and then re-used to display the form in the Web View. The Form Properties dialog shows up when opening a form in design mode, and then clicking on the Form Properties button on the bottom toolbar.
(In reply to Alex Thurgood from comment #12) > > My thinking from a UI perspective would be to allow such attributes to be > set as Height/Width in the Form Properties dialog under the "General" tab > and saved in the ODB file and then re-used to display the form in the Web > View. The Form Properties dialog shows up when opening a form in design > mode, and then clicking on the Form Properties button on the bottom toolbar. Would be also my expectation since other controls have height/width (and x/y) properties accessible in this property dialog. What I do not understand from your explanation, btw. many thanks for the elaboration, is why the form is placed on a document - and adopts the page properties. If Base shows the actual form it could be resized as known from other IDEs. Removing needsUX so the formal hand-over to implementation is done.
(In reply to Heiko Tietze from comment #13) > (In reply to Alex Thurgood from comment #12) > What I do not understand from your explanation, btw. many thanks for the > elaboration, is why the form is placed on a document - and adopts the page > properties. If Base shows the actual form it could be resized as known from > other IDEs. > Just noticed that I had not replied back to you on this one since 2017 - oops ! That's what comes of not being the OP, I guess. I imagine that you will have learned by now that database forms are always either a Writer, or more rarely, a Calc document - historically, this has always been so. As such, they rely on the underlying document model and the interfaces and methods exposed by that document model. The default in LO-Base is to provide Writer forms, which are stored within the embedded database file. For as long as we continue to tie-in form design to Writer documents and the corresponding document model, we will be stuck with this issue of not reliably being able to manually fix form dimensions and have them respected. If we did manage to separate it off some how, some people would moan that they could no longer just print out their form (from Print View mode, as opposed to Web View mode). We would also need to be mindful of not screwing up the export to PDF form functionality (which already has its own issues). Interestingly enough, similar semi-independent functionality is already present in the ReportBuilder - which creates a Writer report document based on an XML definition of the report, and which then translate that XML definition into a Writer document. Aside from the pain of this code being written in Java, I don't know whether the Report Builder allows the user to define a report size independently of the underlying document - I suspect not, as reports are also stored in the embedded database file. It might be interesting to compare with how Kexi did/does things (can't tell whether it has stalled, or is just very low commit rate).