| aacid |
With formatting there is an internal value, which represents
the true value of a field additionaly to the normal,
visible, text.
For fields which have formatting rules these might differ
and for calculations the internal value is used. The behavior
to format on focus in / focus out events is similar to
that of Acrobat reader.
Needs unit test
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I'm not very happy of the internalText method/storage in form, ideally, the text in core/form should always be the internal text, and if there's a formatted text that needs to be different that should only be as part of the widget itself. i.e. the FormLineEdit would do something like
setText( formatText( form->text() ) );
Do you think it could be implemented this way?
| core/document.cpp | ||
|---|---|---|
| 4318 | You can simplify the loop to p->formFields().contains(fft); | |
| 4362 | I don't understand this, can you elaborate why we need to update a form if the new and old text are the same? | |
Sadly I don't think so. I would be happier with such a solution, too, but we need to have the formatted text as part of the real form data so that it is properly printed and shown even if the widget is not visible. Actually the "internalText" is kind of more a "UI" thing while the formatted text is the real thing.
| core/document.cpp | ||
|---|---|---|
| 4318 | ack. | |
| 4362 | If the field was calculated we need to update it anyway because we no longer refresh it in DocumentPrivate::recalculateForms. This avoids a double refresh in case the field is formatted. Old text here is before formatting, but after calculate. New text is after formatting, but still after calculate. Even if the formatting did not change anything we have to update because of the calculate. If I remember correctly this happened to me during development when the Format script raised an exception. I shall clarify the comment. | |
fields in processFormatAction.
| core/form.h | ||
|---|---|---|
| 331 | Do we need these two to be virtual? i.e do you envision a case in which a backend generator would want to reimplement them? It seems to me this is mostly an "internal storage" area for the core and the backends don't really care? | |
| core/form.h | ||
|---|---|---|
| 331 | Saving / loading could be an issue. I'm not sure how we could save the internal text, but maybe someone ingenious will find a way. I mostly did it though to match the rest of the class. ;-) | |