Hi Peter, On 6/20/06, Peter Eberlein <[EMAIL PROTECTED]> wrote:
You are talking about how to realize that with the recent version, the topic is about ..3.0.
yes, that's clear. The prototype is there to get a feeling for the service-properties or features that are missing in formControls of the current version. Having an overview about missing features helps us to get the concept more concrete and to get a list of extensions we have to apply to the existing UNO-services/options/interfaces. 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!
Possibilities for me: Hard coded additional properties for each control, for groups or for the form (all controls get the same shadowing only for layout, the printing background color is the color of the recent property).
yes, this might be a solution. But in the end we need to define all of the required properties in a exact and concrete manner, don't we? [...]
Yes, I've tested your macro, finding the correct position and size may be a little bit tricky. [...] Imo the most significant point is the autosize-feature. It must imply a wrap to the next line, if the content is too long for the actual line. With other words: the behaviour of controls should be similar to a com.sun.star.text.TextField. If this couldn't be solved: may be a new field with formatting options is required. The list field is a new one too because of compatibility reasons.
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). 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)
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. hmm... If you still would like to choose the alternative 1 it might be correct that checkboxes, ... will be a foreign matter, but not if one chooses alternative 2 in which some new TextField services for the representation of comboboxes, ... would be required. regards, Christoph --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
