Issue 65951 - forms handling in OpenOffice 2.x / 3.0 (writer)
Summary: forms handling in OpenOffice 2.x / 3.0 (writer)
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: All All
: P3 Trivial with 4 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 77958 125826 (view as issue list)
Depends on:
Reported: 2006-05-31 12:09 UTC by eberlein
Modified: 2016-01-28 17:25 UTC (History)
10 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description eberlein 2006-05-31 12:09:28 UTC
Especially for Public Administration and for larger companies the current
implementation of forms handling in the broadest sense is not satisfying in
OpenOffice Writer.

There are miscellaneous possibilities for working with forms: input fields,
bookmarks, placeholders or control objects. Bookmarks and placeholders are not
critical, so I will ignore it.
For input fields there are some rfe's in issuezilla yet (see 16641, 33737,
35088, 47799, 50839, 56156). The main points are
- input fields should not pop up when opening the template (because you cannot
see the context)
- should be editable “on click†without prompting
- should be reachable by tab like controls

It should be discussed, if forms handling can be improved much more by using the
possibilities of controls.
A text form field in MS Word can be formatted. For input fields in writer you
don't have such opportunities. This is only one restriction.

If controls could be smoothly integrated into continuous text, I would prefer
this solution of forms handling.
The form than is really a form, you can jump with the tab key from the first to
the last control, you can use all possibilities you got with formatted and
currency fields, masked field etc.

The following must change to reach that goal:

- first an AutoSize option is needed. [1]
- per default the background of controls should be shaded without printing the
background color. If the control gets the focus, the shadowing should be stronger.
- per default there's no need for a border
- by inserting the controls into text, the underlying context must be
recognized, means the char formatting of the control must correspond to the
formatting of the last char of text.
- a property “placeholder text†would be nice, see [1]
- binding the control content to variables without programming [1]
- if controls are inserted into tables, calculating with them must be possible
without programming
for the Rich Text Control, the tab key should work as for other controls
(jumping to the next)
- an option is needed to switch the scroll wheel off for some controls. In
practice the users often overwrite entries in controls accidentally during
scrolling. That's very annoying when these data are used for workflow.

These requirements may collide with the needs of forms in base, but this could
be solved as follows:
If the control was created with a wizard or by drawing with mouse, then the
control gets the properties in the current existing implementation.
Additionally we need another possibility to insert a control. This could be
realized in the menu bar with Insert->Form Field->Type of Field or by
doubleclicking on the icon in the bar “forms-control elements†(transl. from
German) or both.
Then the control is inserted at the viewcursor position in a defined size
dependent from context with the properties described above.

If this could be realized, than the import filter for MS Word should transform
listboxes and text form fields to controls in OpenOffice.

Comment 1 michael.ruess 2006-05-31 12:28:21 UTC
Reassigned to MSC.
Comment 2 marc.neumann 2006-05-31 13:21:35 UTC

I reassign this enhancement to the User Experience team for evaluating.

Bye Marc
Comment 3 Mechtilde 2006-06-03 22:47:29 UTC
Comment 4 michael.ruess 2007-05-31 09:29:13 UTC
*** Issue 77958 has been marked as a duplicate of this issue. ***
Comment 5 oooforum (fr) 2016-01-28 17:25:55 UTC
*** Issue 125826 has been marked as a duplicate of this issue. ***