[Libreoffice-ux-advise] [Bug 82320] Form properties should include static width, depth.

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=82320

--- Comment #12 from Alex Thurgood <iplaw67 at tuta.io> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.