Apache OpenOffice (AOO) Bugzilla – Issue 33737
Allow for in-place editing of input field (turn off pop-up)
Last modified: 2017-05-20 10:35:21 UTC
Input fields are currently edited using a dialog box that pops up when clicking the field. It would be more intuitive, faster and practical to edit these fields in-place instead of through a dialog. Ideally they should also allow for direct formatting as well. This enhancement would also increase compatibility and interoperability with MS Word. Text fields in Word forms are imported as input fields. In that respect, Input fields should be integrated with form fields (see issue 16641).
reassigned to BH.
*** Issue 52468 has been marked as a duplicate of this issue. ***
setting keywords, reassigning
*** Issue 63429 has been marked as a duplicate of this issue. ***
Taking over to hack around ab bit:-) Adding mba on cc
*** Issue 35088 has been marked as a duplicate of this issue. ***
Created attachment 44228 [details] patch file - first step
The attached patch replaces the SwInputField with a bookmark based input field. Missing features of this patch (to name a few, not all): no real undo, no fly-over-help, no Edit/Field support, no word import, To be file-format compatible the field must not contain paragraph breaks or other objects like frames, tables, other fields etc. Character attributes are also limited to the complete field. These conditions are not handled with the patch. Text insertion into the field works only after the first and before the last character of the field text. (->fme)
*** Issue 79720 has been marked as a duplicate of this issue. ***
How does one go about determining the status of this bug? Is there any possibility that this will be fixed in 2.3? Please see the dup # http://www.openoffice.org/issues/show_bug.cgi?id=79720 for added information. Since submitting that dup, I now have 2 schools, 1 library, 1 fire station, and 1 additional police department that will not migrate to OOo because of this issue. Please change from "Enhancement" to "Defect".
Started implementation. Have inline input and .DOC import working. Currently implementing .DOC export. If anyone is interrested testing the current import let me know...
Great news! Thanks for starting the implementation. I would like to help testing the import. Is it possible to get a cws for testing?
A snapshot of the current work can be found here: http://florianreuter.blogspot.com/2007/10/update-on-field-work-early-preview.html.
Yes! Initial test using the NZ Customs form on linux (Ubuntu Feisty 7.04) works! Even the check boxes work as expected. Thank you so much for working on this Florian. Tested on a police department form - fill-in boxes work, drop-down tables work however tabbing skips the drop-down tables so you need to use the mouse to get to them. If you'd like the police department form, I do have permission to send it to you directly.
Thanks so much for the testing. Sure send the doc to freuter@novell.com. I'll treat it confidentially. I hope you have time to test the next versions too :-) Thanks again, ~Florian
Hi Florian, from what I can tell this is exciting new stuff for OOo! Tabbing back and forward works as expected and by filling out the fields inline, a lot of sacred* user time is saved. MMP-1) regarding the color of the controls: Obviously you chose a kind of blue for the input fields -- where MS uses gray. I prefer the light blue but ask at the same time if this is customizable by the form designer? I can imagine that some high payed agencies like to tune the color according to the look of the document. MMP-2) regarding the check-box controls: Tabbing into the check box and hit space to mark the control works fine. But I suppose you should also provide a way to actually click the checkbox to set the mark. BTW - this works fine in the current releases of OOo. MMP-3) Initialfocus Do you know if one can create a form with the first input field focussed already? You know much better than I what kind of controls to support. I just did a quick review of your sample document. But I guess my feedback issues bring us closer to a very good new feature for OOo. cheers, Matthias :: ux co-lead
target 3.0
Florian, are we on track for 3.0 with this enhancement? Does it need to be finished before feature freeze or code freeze?
here's an example of why i feel the popup is so clunky. http://www/presence/connect/www/home/forms_fees/forms/alphabetic_forms/fcoa_form_affidavit rab the word version and open it up. Go to section D. This is a free form text input in a protected document. It should be able to cope with larger amounts of text (many pages even ?) but having a small window popup doesn't really allow for large free flowing text. thank in advance H
flr->hiney: Looks like your link is broken --- it only shows me www.yahoo.com... I'd really love to see the doc... flr->kpalagin: Current plan it to get it into OOo 3.0.
Btw. Current patches can be found in: http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/officecfg-field-patch.diff?view=markup http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/svtools-field-patch.diff?view=markup http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/offapi-field-patch.diff?view=markup http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/sw-field-patch.diff?view=markup http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/xmloff-field-patch.diff?view=markup Description of the ODF enhancements needed for this feature are described in: http://florianreuter.blogspot.com/2008/02/xml-namespaces-are-designed-to-support.html.
Florian, thanks a ton for your answer! Is the patch ready? Do you have an estimate of when it will be integrated into SRC?
flr->kpalagin: Had a chat with mba about it. The current plan is to get it into OOo3.0 but disable it by default (since some UI features etc are missing). However since it can be turned on by a simple configuration change interrested users can turn it on by eg. installing an OXT extension. Once the feature is complete we'll installl the extension by default. Does this make sense? flr->mba: Is this plan still valid? Could your team do a quick review of the patches I linked to check feasability of this plan and confirm that nothing is broken when the fearure is turned off?
@flr: Yes, this plan is still valid. Of course we could have a look on the patch. It would help if we could apply it to a CWS instead. In that case we would need the confirmation that this code is contributed under the JCA. @kpalagin: As Florian mentioned, we still have some open points. But we are very committed to solve them so that I am very confident to have this in 3.0 or 3.0 Beta.
flr->mba: Yes; will do that. As you know my arm is broken and the cast will be on for one additional month :-( Typing is a pain --- so some help in CWS creation would be great :-) I'll send you a seperate email with the patches and the JCA for that patches.
doh !!! once more with the full domain shall we :-) http://www.familycourt.gov.au/presence/connect/www/home/forms_fees/forms/alphabetic_forms/fcoa_form_affidavit
flr->hiney: Thx for the sample docs. Seems to work fine (at leasr the .DOC / .RTF is not ready yet).
Thanks Florian, I will commit the changes to a CWS and report back.
Florian, thanks again for continuing to work on this issue. Are there any updated previews (since the Oct one's) that can be downloaded for testing? I'd be happy to test in Linux (Ubuntu 7.10) and Windows (XP Pro).
I just received an email asking me to comment on this issue. I guess I don't know how to download the patch to test it. We are converting our school district to open office and have run into problems with templates that have Microsoft Form Fields in them. If this issue can be resolved it will fix many of our problems.
Hi, the preliminary work is integrated in http://go-oo.org/. The upstreaming in OpenOffice.org is in progress. So for testing downloading a build from http://go-oo.org/download/ should be fine. As said: At the moment only inputboxes and checkboxes are working. Drop-down lists are in progress. ~Florian
An "upstream" build will be available for testing shortly. Unfortunately the patch didn't fit very well into the upstream code and it took several weeks to get it running. But now we have it. :-) We will give URLs for download here soon and we will be very grateful for every testing.
In our qa-upload.service of OOo you will find installation sets for Linux, Solaris and Windows: ftp://qa-upload.services.openoffice.org/EnhancedFields/ Please download, test it and report problems to us...
I was able to download and install the software you wanted me to test. What I found is when you open a Word document that was created with Text Form Fields it converts them to Input Form Fields and I was able to type in place on most of the fields without a problem. There were a few problems where sections were skipped but you were able to click with your mouse to back up to those sections and type in them. I don't understand why the tab order would change like that. It skipped whole sections of the 10 page document. We also tried bringing up a one page document with about 35 text form fields in it. We were able to type in every field which seemed great but then the secretary tried to scroll back up to the top of the form and each time the screen became totally disoriented. I will send a few screen shots to the email addresses I have. I don't understand why that would happed either. I also tried to make a new document in Writer and insert input fields. They seemed to work like they previously did with the dialogue box popping up. I tried saving it as a .odt and a .ott and both documents continued to work like the old input field where the dialogue box popped up. I'm not sure why it would act that way.
Hi, Just created some documents in Word with formfields: text, check and drop-down. - The checkboxes could be navigated by the tab key, when 'protection' was on, and changed by the space bar. - The text- and dropdownfields could not be navigated nor changed (direct or via pop-ups), when 'protection' was on. Pls let me know if further testing on this or newer build is useful. Thanks, Cor
@Cor: You can test with the New Zealand 'Ship Inward Report' listed here: http://www.openoffice.org/issues/show_bug.cgi?id=79720 <http://www.customs.govt.nz/nr/rdonlyres/af900edf-a296-450a-a78b-d3f190e234b7/0/formc1new.doc> To see how the document might appear to customs agents, protect the section & allow editable in read only document (File|Insert Section). @Florian: I've tested with the Windows version (in Win2KPro via a VirtualBox VM) and the results are as in October: tabbing between form sections work, however the tabs skip still over the drop-downs on the form. I used the Atlanta Police form (Preliminary Investigation Report) that we tested with previously for this. Can you please test using that document? If you need it again, let me know and I'll send it to you directly. Failure to tab to the drop-downs is a showstopper IMO as: 1) the feature is inherent in MS Word documents with forms & those users will be accustomed to this, and 2) in the real life case; the police officer will not be able to easily complete the report if he/she needs to screen touch or mouse back to the drop-down sections. Ditto for a customs agent, or anyone else that have forms with drop-downs. I am having difficulty with the linux version as I found that I need to install as a parallel version; it interferes with the existing Ubuntu (U)OOo and the installed 3.0BetaM14 version. It's not a big problem, I'll test with linux by tomorrow. I very much would like to see these changes for 3.0 (final), so I will be happy to assist with any testing you'd like.
Tested with linux (Ubuntu 7.10 - Gutsy - 2.6.22-14-generic) installed as a parallel install in the user home directory. The results are the same as the test with the Win2KPro: tabbing and entering data in the form boxes works great, shift-tab moves back to the previous properly, but tabbing skips over the form drop-downs.
AFAICT a new field type is being used for in-place editing. Why has this approach been chosen? It means that we cannot benefit from this feature for all our existing forms and it requires extensions to the ODF format which creates non-ISO-standard documents. It would be a lot better for users if they could simply switch existing form fields to in-place behaviour. I'd go so far to say that no one would complain if the pop-up UI were completely scrapped in favour of in-place editing. That's what Word does, after all.
flr->mux2005: You're right! However --- the main reason this issue is open for many years is that with the existing fields implementation in the OOo Core an in-place editing is not possible. So the only option was to design a new field type. There where many attempts to add in-place editing to the existing fields and it turned out that we need a new field implementation in the Core. Wrt. to ODF there is a proposal to add the new field types to ODF.
I can understand that the internal data structures may have to be changed to support in-place editing, introducing field marks as detailed in the blog post linked to in one of the comments, but that is no reason to introduce them into ODF. Lack of in-place editing is not a shortcoming of the ODF format. There's no technical reason (aside from choosing the path of least resistance) why OOo's internal data structures need to map 1:1 onto the ODF file format, and extensions such as this break confidence in the standard and hurt interoperability. If ODF is to be taken seriously, then we mustn't have the same situation with OOo that we have with Word, namely that only the latest version of OOo is capable of reading all ODF files properly.
flr->mux2005: That not true! E.g. fields of the form: Some Comment: <field-start>....\par ....\par ....</field-start> can *not* be represented with the current ODF fields. So I really tried to get it right this time and not come up with yet another crappy solution. Another thing is e.g. #29508# which can *not* be represented by the current ODF fields. Your statement may be right for what you have in mind, but its not true in general.
*** Issue 49604 has been marked as a duplicate of this issue. ***
Will be integrated into 3.1
Assigning to self: integration of code introduced in cws swenhancedfields2 (issue 93321).
depends on 93321.
b_michaelsen, will this be integrated in 3.1? Regards, KP.
@kpalagin: Im sorry, but I cannot guarantee that this will make it into 3.1. I am working on a refactoring/cleaning up of the whole mark/bookmark implementation. This is mostly done by now (cws swrefactormarks2), however there are still some issues with the new implementation of input fields (form protection among others), so it is still open if this will make it to 3.1. HTH.
retargeting -> 3.X
Not even 3.2?!
The patch contains some unsolved problems and we have no time line when they will be fixed. So instead of always assigning it to the next target and move it in case we don't have the necessary fixes, we do it the other way around: use 3.x and switch it to the next possible one in case the bugs are fixed.
CWS swenhancedfields2 has already been integrated into DEV300m31. What is left to allow this issue to stay open ?
For what it's worth, input boxes and check boxes are working very well in: $ cat /usr/lib/openoffice/program/versionrc [Version] AllLanguages=en-US BuildVersion=openoffice.org-core 1:3.1.0-5ubuntu1~jaunty1, Thu Jun 18 19:30:05 UTC 2009 buildid=310m11(Build:9399) ExtensionUpdateURL=http://updateext.services.openoffice.org/ProductUpdateService/check.Update OOOBaseVersion=3.1 ProductBuildid=9399 ProductMajor=310 ProductMinor=11 ProductSource=OOO310 UpdateID=OpenOffice.org_3_en-US UpdateURL= UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages}) Vendor=Debian and Ubuntu $ apt-cache policy openoffice.org openoffice.org: Installed: 1:3.1.0-5ubuntu1~jaunty1 Candidate: 1:3.1.0-5ubuntu1~jaunty1 Version table: *** 1:3.1.0-5ubuntu1~jaunty1 0 500 http://ppa.launchpad.net jaunty/main Packages 100 /var/lib/dpkg/status 1:3.0.1-9ubuntu3 0 500 http://archive.ubuntu.com jaunty/main Packages Which is based on the go-oo branch per Florian's comments of: ------- Additional comments from flr Tue May 13 13:15:54 +0000 2008 -------. As said: At the moment only inputboxes and checkboxes are working. Drop-down lists are in progress.
As described in some comments, the patch still is too buggy and so we had to disable it. We integrated it in disabled state to synchronize the code with ongoing development.
In the version of the patch we received the protected section feature was broken by the new code. I wonder why someone integrates a fix with a half-done feature and breaks another very important feature with it, but anyway, it's not like I want to do it. I don't know if the problem with protected sections was fixed in the build you mentioned. I'm still waiting for an answer from flr.
protected section feature is broken in recent go-oo builds. I had several users complaining about this. The critical thing about this bug is that you never ever can unlock a section in a word document after it has been processed by go-oo (even not if you convert to odt).
So the decision not to activate the patch was right. I don't know if the users of the go-oo.o build prefer new features over product quality, I don't believe our users will do it. We have reported the bug to the go-oo.o guys at the OOoCon in Bejing last year, I hope that some day it will be fixed.
So the decision not to activate the patch was right. I don't know if the users of the go-oo.o build prefer new features over product quality, I don't believe our users will do it. We have reported the bug to the go-oo.o guys at the OOoCon in Bejing last year, I hope that some day it will be fixed. ======================================================== I suppose that there may be issues with the patch/work provided by Florian, but at least he provided work (perhaps buggy?) that progressed beyond the standard OOo forms. I'm not a dev, but a user that sincerely wishes to see OOo installed in corporate and government sites, but that is unlikely to happen if this is not resolved (see: http://www.openoffice.org/issues/show_bug.cgi?id=79720). Not to be confrontational, but have you ever used an OOo form based document on a daily basis in a corporate or government environment, or know of any that do? If so, how did you train them to do this?
Exactly the form mode is broken in the patch as it quite often requires protected sections (only the fields are editable, but not the text in between); so the patch has improved text fields but they are not usable in forms. I have asked for an improved patch very often. I don't want to wait for much more time now. I agree that this feature is important. If the patch submitter won't fix it in an acceptable time frame, we will either fix or re-implement it ourselves.
FYI, flr created cws field01 to resolve remaining issues and finish the integration. However, I cant comment on the progress made there.
I just noticed flr isnt even cc'ed on this bug -> CC'ing flr. P.S.: Also cc'ing od.
blocking 101312
*** Issue 47799 has been marked as a duplicate of this issue. ***
Any progress / workarounds for this by now? Still crappy input field editing with 3.3 m20!
pls. reassign or close issues. Thx.
YES - Please continue to work on this patch! Has there been any recent progress ? Thanks! -- Russ T.
I am working on a solution for this UI issue. I am _not_ planning to introduce a new/changed 'input field' with more features. I am just planning to enable the in-place editing of the current existing 'input field' which is represented in the OpenDocument file format by ODF element <text:text-input>. My current plan for the in-place editing: - Return-Key will be handled as if the user has inserted a line break - no start of a new paragraph. - Only text content will be allowed inside an 'input field'. - Character formatting, like Bold, etc., will be applied to the complete 'input field'. - Try to enable in-place editing, when text document is in read-only mode. - In read-only mode traveling from 'input field' to 'input field' via Tab (next) or Shift-Tab (previous). Open questions: - If traveling via Tab/Shift-Tab is active, how to insert a Tab character as content into the 'input field'? - Is traveling needed in standard document text editing mode?
"orw" committed SVN revision 1525917 into trunk: 33737: - some minor refactoring in advance
Great to hear, that you continue working on it! I would insert a tab character with Ctrl + Tab (as in Word input fields and in Writer tables). From my point of view travelling is needed in text editing mode, because many documents that are used as forms have to be edited also outside the input fields.
(In reply to jr from comment #68) > Great to hear, that you continue working on it! > > I would insert a tab character with Ctrl + Tab (as in Word input fields and > in Writer tables). > This is a good idea. It is consistent with the 'table traveling' and the inserting of a tab character inside a table cell - it is known to the user. > From my point of view travelling is needed in text editing mode, because > many documents that are used as forms have to be edited also outside the > input fields. Ok.
I am making good progress on the solution of this issue. I have started the documentation of the solution in our wiki - please have a look at https://wiki.openoffice.org/wiki/Writer/Input_Fields. It is still not complete, but it make sense to have a look an provide feedback in this early stage.
"orw" committed SVN revision 1542986 into trunk: 33737: enable in-place editing of Input Fields
"orw" committed SVN revision 1543006 into trunk: 33737: remove accicently added svn property 'svn:executable' at new source files
solution for the in-place editing of Input Fields as documented in the wiki (see comment #70) integrated into trunk.
"orw" committed SVN revision 1549864 into trunk: 33737: correction: assure the selections does not start/end inside a table wh...
(In reply to SVN Robot from comment #74) > "orw" committed SVN revision 1549864 into trunk: > 33737: correction: assure the selections does not start/end inside a table > wh... I have to admit that my changes for the in-place editing broke the text selection function which assures that a made selection does not start/end inside a table while it ends/starts outside the table. The above change fixes the broken code.
Now a double click in the field opens the "Edit fields" dialog, which is pretty much useless, since it does not allow edition despite the name. Wouldn't it be better if double-click could open the old pop-up dialog instead? The new inline feature would still work, and there would be a way to use the old solution, which can still be usefull as a fallback in some situations, like copy-and-paste and nostalgic users;) Looks like a win-win cenario, since it would then combine the strengths of both solutions: one would normally use inline editting, which is fastest, but could use the dialog if he so whishes.
(In reply to Atila from comment #76) > Now a double click in the field opens the "Edit fields" dialog, which is > pretty much useless, since it does not allow edition despite the name. > Yes, I put on double-click the same function as Context Menu - Fields. > Wouldn't it be better if double-click could open the old pop-up dialog > instead? The new inline feature would still work, and there would be a way > to use the old solution, which can still be usefull as a fallback in some > situations, like copy-and-paste and nostalgic users;) > > Looks like a win-win cenario, since it would then combine the strengths of > both solutions: one would normally use inline editting, which is fastest, > but could use the dialog if he so whishes. I like the idea. Would you be so kind and submit a corresponding enhancement issue? You can put me directly on CC. The 'old' function 'edit all input fields starting on the first one' which is available via Shift-Ctrl-F9 also opens the 'old' edit input dialog, but has the additional button 'Next' in order to switch to the next input field. May be it would make sense to open this 'old' dialog when performing a double-click - just a thought.
(In reply to Oliver-Rainer Wittmann from comment #77) > (In reply to Atila from comment #76) > > Now a double click in the field opens the "Edit fields" dialog, which is > > pretty much useless, since it does not allow edition despite the name. > > > > Yes, I put on double-click the same function as Context Menu - Fields. > > > Wouldn't it be better if double-click could open the old pop-up dialog > > instead? The new inline feature would still work, and there would be a way > > to use the old solution, which can still be usefull as a fallback in some > > situations, like copy-and-paste and nostalgic users;) > > > > Looks like a win-win cenario, since it would then combine the strengths of > > both solutions: one would normally use inline editting, which is fastest, > > but could use the dialog if he so whishes. > > I like the idea. > Would you be so kind and submit a corresponding enhancement issue? You can > put me directly on CC. Ok, created issue 125108. > > The 'old' function 'edit all input fields starting on the first one' which > is available via Shift-Ctrl-F9 also opens the 'old' edit input dialog, but > has the additional button 'Next' in order to switch to the next input field. > May be it would make sense to open this 'old' dialog when performing a > double-click - just a thought. Sounds good to me. Thanks.
(In reply to Atila from comment #78) > (In reply to Oliver-Rainer Wittmann from comment #77) > > (In reply to Atila from comment #76) > > > Now a double click in the field opens the "Edit fields" dialog, which is > > > pretty much useless, since it does not allow edition despite the name. > > > > > > > Yes, I put on double-click the same function as Context Menu - Fields. > > > > > Wouldn't it be better if double-click could open the old pop-up dialog > > > instead? The new inline feature would still work, and there would be a way > > > to use the old solution, which can still be usefull as a fallback in some > > > situations, like copy-and-paste and nostalgic users;) > > > > > > Looks like a win-win cenario, since it would then combine the strengths of > > > both solutions: one would normally use inline editting, which is fastest, > > > but could use the dialog if he so whishes. > > > > I like the idea. > > Would you be so kind and submit a corresponding enhancement issue? You can > > put me directly on CC. > > Ok, created issue 125108. Thanks. > > > > > The 'old' function 'edit all input fields starting on the first one' which > > is available via Shift-Ctrl-F9 also opens the 'old' edit input dialog, but > > has the additional button 'Next' in order to switch to the next input field. > > May be it would make sense to open this 'old' dialog when performing a > > double-click - just a thought. > > Sounds good to me. > Ok. I will add this suggestion to issue 125108 > Thanks.