Apache OpenOffice (AOO) Bugzilla – Issue 68660
Improvement of Input Field Dialog
Last modified: 2013-08-07 14:42:39 UTC
Input Field can be used to make e-form which user can fill in specific area while others are protected. Another kind of e-from is made in MS Office using “Text Form Fieldâ€, and open in OpenOffice. Well in OpenOffice, users have to click on the input field, then popup a dialog, then input the value in the dialog, then click OK, then dialog closed and value of input field is updated, then click the next Input Field and repeat these steps. As shown in Figure 2. If the e-form has a lot of fields, the behavior of OpenOffice becomes very low efficiency, and the user complain it as almost unusable. This patch is an improvement of the original dialog, to make the input of large amount of input fields much easier. We add “Previous†and “Next†buttons to the dialog. If the user press these buttons, it will save the current input field, then move to previous or next input field, and display the value of previous or next input field in the edit area of dialog for user to edit it. In this way, the users can edit all the input fields without leave the dialog. We add shortcut key for all the buttons, so the user can operate all the functions without using mouse. And, we make the dialog position just above the current Input Field, so the user can know which field is in edit clearly. Finally, we make the field update instantly, this means, when the user modify the content in dialog, the field content will update immediately, no need to press “OK†button. This make the user has some similar feeling as inline edit. By the way, if user modify the content instantly, and then click “Cancel†button, it will close the dialog and restore original as usual.
Created attachment 38545 [details] The Patch
Created attachment 38546 [details] Document of the patch
Created attachment 38547 [details] Test sample for the patch
Reassigned to ES. Please evaluate with OS and UserEx.
ES->MMP/OS: interssing *patch*! The changes I would agree with: 1) Moving the dialog above each field in the document. 2) Button Next and Previous. Note: one can already cycle through all fields pressing Ctrl+Shift+F9 for the first field and then Ctrl+Enter but in th current implementation: a) There is no "Previous" possibility. b) The Next/Prvious is not visible in the UI. 3) Simultaneous update of the field while typing. 4) Revert Content on Cancel. I would NOT agree on converting the multi-edit field into a single line edit field simply because on may need to use multi-line input fields. :) Please think about a target. Please set
Zhang - seems we need to undo the multiline edit change :-)
->mypersonal: Editing InputFields looks fine to me. But you didn't ever insert an InputField with your new dialog, did you? It crashes while inserting an InputField in SwFldInputDlg::ModifyHdl. The access to GetCurFld() usually returns NULL in case of an insert of a field. And also the Next/Prev buttons don't make sense when inserting a new field. The dialog needs and 'insert mode' (parameter bNextButton is currently unused).
Fix the bugs: 1. enlarge the edit box, so user can know it is a multiline edit clearly 2. For newly insert input field, hide the previous and next button, and fix the crash bug. 3. adjust the dialog position more smart and resumit the modified patch
Created attachment 38773 [details] New patch with bug fixed
Did you test the case that input fields and list fields are alternating in a template? And don't forget to write a new spec... ;) 2.1 is coming soon.
retarget
Unfortunately mmp didn't respond so we missed the deadline for 2.2. Oliver, please review the new patch.
Sorry to say, but there are still some severe problems: - In case of expression input fields (pSetFld is set) the dialog crashes in the second call of Apply() because this member is not updated after updating the field After Next/PrevHdl are called the members pSetFld and pInpFld both have to be updated. - In ModifyHdl there's no code to care for this pSetFld The resources of OKButton, CancelButton and HelpButton must not have Text entries. The labels of these buttons are provided via VCL from the window system.
@mypersonal: are you still working on this patch? According to OS the current patch can't be integrated as it lets OOo crash in some cases and it also seems to miss something.
Obviously the patch was abandoned. So I will close this issue soon.
done as proposed
Despite the fact that patch seems to be abandoned the issue is still valid and we probably should reopen it in case somebody else picks it.
nah - Florian has a much improved version of this that does nice in-document field support, making this older stuff deprecated & un-necessary - hopefully we'll have much better field support, based on that in 3.1. HTH.
Yes, we already have integrated the patch from Florian Reuter and adapted it to the recent code line. For the 3.1 release we will fix the bugs found so far and some open points and refactor the code for our new Bookmarks classes that are currently designed and implemented to support metadata fields and "text meta" elements. We will either provide a new dialog or (preferred) switch the old dialog to support the new fields.
close the invalid issue