Hi Christoph,
Christoph Lutz schrieb:
The prototype for example shows another thing that should be
considered: The com.sun.star.form.component.TextField has a property
"RichText" that is responsible for the representation of the content.
If this property is "false", the text is always shown in a default
fontstyle, regardless of which stylings are set, but the navigation
with TAB work fine. If this property is "true", the formatting is
correct, but the navigation with TAB does not work!
I mentioned this in issue 65951 and filed 66674 for that.
[...]
imo the question is which is the best uno-service that could be used
as a base for the extensions. Currently I see two alternatives:
1) extending com.sun.star.form.component.TextField (FormControl) or
2) extending com.sun.star.text.TextField (TextField).
Or both, the autosize feature is on the todo list of the base team...
After writing the prototype It seems to me that extending the
TextFields (2) should be much easier than extending the FormControls
(1) as TextFields have much more in common with the wanted
behaviour/functionality than the FormControls have. Please also
consider the formmating-issues I noted above, which are not there if
you chosse alternative 1. Using the TextField as a base, primary the
navigation-task has to be extended, while using the formControls as a
base there are many open questions (see above)
After balancing pros and cons:
Agreed to solution (2).
With the rich text control you have formatting options, with TextFields
you don't have (for a part of the inserted text, and IIRC Microsoft Word
doesn't have it too).
With other fields (date and numerical types) you have formatting
options, which you will miss with TextFields in the current
implementation, and the Word textfield has some of this options too.
But how to jump with the tab key? The checkboxes (or radiobuttons) will
then be a foreign matter in this context.
Using the alternative 2, the TAB-navigation should be easily be
implemented with a new eventListener that listens for Key-Events and a
special handling for the TAB-key.
Don't know if this would be easy, because the listener has to know which
type of "jump-to object" (may be a checkbox control or a field) is the
next one to focus...
And don't forget: Word has for example two types of CheckBox objects,
one for filling forms and with the look and feel of text fields (form
bar), and one similar to the OpenOffice one (in the controls toolbar).
May be doing this way in OpenOffice too would be the best to fit the
needs of the user.
That means:
1. Reworking the behavior of the input field (no popup, formatting
options, standard size)
2. Implementing a new field type "checkbox" (a type "radiobutton group"
would be a nice to have feature), binding the state of the field to
variables like input fields do.
The latter is important, because if you have a form with 30 paragraphs
(each with a checkbox) and only two are checked and should be printed,
you can achieve this easy with fields (hidden paragraphs). Until now you
have to realize this with macro programming.
3. Binding the selected value of the list field to variables, popup
necessary?
4. Implementing the tab key behavior for all those fields
5. Extending the service com.sun.star.document. It has a boolean
property "AutomaticControlFocus". Here we need a similar option for fields.
Regards
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
