Hello, I have been getting nothing but complaints and users begging me to downgrade them back to 4.1.6 after updating them to 4.2.4, just for this one new feature. The new inline method for editing Input Fields in text templates is simply much less convenient and more error prone - even if/when the current problem of not being able to copy/paste from/into these fields is fixed. Personally, I can see the argument for both ways, but I also can say that these pop-up fields is one thing that I have always liked *better* than the inline way that Microsoft does it. I am begging the Libreoffice development team to provide a simple user preference/option to allow reverting to the old behavior of editing these fields in pop-up mode. Please, please please allow the users the choice. Thanks for listrening.
Seconded. The inline method is awkward and obscures the nature what you're actually doing - as someone who's had to work with the Word implementation for years now I must say LO's old popup method was vastly preferable.
That said, I really don't want to give the impression that I think the current situation is anywhere near as bad as it is in Word. Only being able to put text in the field with no in-field formatting allowed still saves me a world of headache and I'm still generally able to easily tell where one field ends and another begins. I've seen some discussion elsewhere about possibly making double-clicking on an input field bring up the old popup, but a preference that could be turned on and off would probably be better for the mouse buttons and fingers of people who will ordinarily use that method rather than inline.
Can you confirm that this worked in LibreOffice 4.1.x ? If it is the MS Office compatible text fields work that was done way back in the 3.x series. And/or can you attach a simple sample document with idiot-user instructions: "move the cursor to here", "type XYZ" etc. that has this feature working as you like it in 4.1.x ? Thanks.
Hi Michael, Thanks very much for taking a look at this! (In reply to Michael Meeks from comment #3) > Can you confirm that this worked in LibreOffice 4.1.x? Yes, this worked perfectly in 4.1.x and all prior versions. We've been using Libreoffice since its first official release, and Openoffice prior to that, since version 1.0 was released. I honestly don't remember when 'Input fields' were introduced or when we started using them, all I know is that we have been using them for a very long time - I'd have to say at least since about 2003 or so. > If it is the MS Office compatible text fields work that > was done way back in the 3.x series. This is definitely not that - here is the bug responsible for this new inline editing of Input Fields (again, introduced in 4.2): https://issues.apache.org/ooo/show_bug.cgi?id=33737 So... >= 4.2 introduced the new 'Inline Editing' method for editing Input Fields, which is the way Word has always worked. <= 4.1.x edits existing Input Fields in the same pop-up dialog that, incidentally, is still used in 4.2+ when populating them the very first time (it cycles through them all, then the dialog closes), when creating a new document from one of the templates. I understand the desire that people have for doing it this way, and in fact, I have come around to not hating it, but I still prefer the old way, hence this bug/enhancement request. > And/or can you attach a simple sample document with idiot-user instructions: > "move the cursor to here", "type XYZ" etc. that has this feature working as > you like it in 4.1.x ? Certainly, but it will just be a simple one for demonstration purposes (our forms mostly have confidential info in them). We have dozens of forms (saved as templates - ie, .ott) with lots of Input Fields (some with 30 or more) that were created many years ago, and have never had a problem with them until the 4.2.x series. Thanks very much again Michael for taking a look at this, even if it is just to confirm it...
Created attachment 107260 [details] Simple Template illustrating the bug Simple Template illustrating the bug (inability to paste into an Input Field) and other problems with the new Inline Editing feature
*** Bug 75319 has been marked as a duplicate of this bug. ***
Oh, one more thing... I would be perfectly happy if, instead of an option, a new 'feature' was added that allowed the user to open the pop-up dialog for a field by simply dbl-clicking the field. Maybe this would be much easier than having to deal with the code required to add an option that could be enabled/disabled?
Ok... The new in-line editing of Input Fields feature was apparently inherited/pulled from Apache Openoffice. Atila created an issue for this for Apache Openoffice, and the developer there who was responsible for the new in-line editing feature appears to be interested ini adding this new feature to allow for dbl-clicking a field to pop-up the old field editor. He also is interested in adding a new 'Previous' button to work in conjunction with the 'Next' button, to allow for cycling through the fields in both directions. I added my comments and thoughts there, so hopefully this will get fixed there: https://issues.apache.org/ooo/show_bug.cgi?id=125108
*** Bug 108522 has been marked as a duplicate of this bug. ***
The in-place field editing is very useful, but as noted the old dialog really was efficient for sequentially completing a form template, and unfortunately the current "Edit Fields" dialog does not provide editing of the field values. You can change the field(s) but not the actual content. Not the best for completing a form. While the old dialog probably needed to go, the "Edit Fields" dialog needs rework to supplement the in-place field editing.
(In reply to V Stuart Foote from comment #10) > While the old dialog probably needed to go, the "Edit Fields" dialog needs > rework to supplement the in-place field editing. I think the old dialog still has its value as you can simply enter the values without all the clutter the "Edit fields" dialog has. The old dialog is still there and appears at startup when opening a document which has fields, e.g. the attachment on this bug. It can also be accessed via Ctrl-Shift-F9. I think entering values in a field is used much more often than editing a field, so maybe changing the double click action to open the old dialog makes sense. And by now it should be clear that in-field editing is not the best option for many use cases. == Suggestion: == As you can reach the "Edit Field" dialog via the context menu, we should change the double click action to open the "old" dialog instead. Would you be ok with this solution?
(In reply to Samuel Mehrbrodt (CIB) from comment #11) > == Suggestion: == > As you can reach the "Edit Field" dialog via the context menu, we should > change the double click action to open the "old" dialog instead. > > Would you be ok with this solution? Yes it would be reasonable to change double click action the open "old" Input Fields dialog (rather than the Edit Fields dialog). But the "old" dialog (currently reached with F9_SHIFT_MOD1) needs refactoring that would make it suitable to task: 1.) "old" dialog's default is to now position at the start (the first text:text-input field) in the document. Instead the dialog should open positioned to the field with cursor focus and the double-click originates. 2.) the "old" dialog needs a Previous button action to complement the Next button. In other words logic to allow movement in both directions through fields of the form--currently it is one way sequential from start of form.
(In reply to V Stuart Foote from comment #12) > > Would you be ok with this solution? > > Yes it would be reasonable to change double click action the open "old" > Input Fields dialog (rather than the Edit Fields dialog). Good idea, > But the "old" dialog (currently reached with F9_SHIFT_MOD1) needs > refactoring that would make it suitable to task: > > 1.) "old" dialog's default is to now position at the start (the first > text:text-input field) in the document. Instead the dialog should open > positioned to the field with cursor focus and the double-click originates. > > 2.) the "old" dialog needs a Previous button action to complement the Next > button. In other words logic to allow movement in both directions through > fields of the form--currently it is one way sequential from start of form. Even better.
Bernhard Widl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad7bc2f7bbf8497ec83c65719ac0d65459293480 tdf#79877 add button text for 'previous' button (gtk-media-previous) It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bernhard Widl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7d5245848c28f5786258476cd7aa2a4523645de3 tdf#79877 revert to old behavior when clicking on input fields. It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On windows 10 Pro 64-bit en-US with Version: 6.0.0.0.alpha0+ (x64) Build ID: 7d5245848c28f5786258476cd7aa2a4523645de3 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-09-19_00:44:40 Locale: en-US (en_US); Calc: CL Thank you Bernhard! Behavior seems functional now. The double click on a field value launch of the Input Field dialog works nicely. Kind of seems the Edit -> Fields... entry needs adjustment to "Edit Field" (as for bug 112382) and that this needs its own Edit menu entry "Input Field" to pop open the dialog.
(In reply to V Stuart Foote from comment #16) > Behavior seems functional now. Indeed - Thanks Bernhard & Thorsten. Set to Fixed > Kind of seems the Edit -> Fields... entry needs adjustment to "Edit Field" > (as for bug 112382) and that this needs its own Edit menu entry "Input > Field" to pop open the dialog. Different bug..
thanks again! Verified in Versie: 6.0.0.1 Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU-threads: 4; Besturingssysteem: Linux 4.13; UI-render: standaard; VCL: gtk2; Locale: nl-NL (nl_NL.UTF-8); Calc: group
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fb5ca6cc9cc55a4436a36c533461769b1fc8526 tdf#79877 perf loading docx file, writerfilter/ improvements It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e6afbe65c75c919665927f62efa21140a020d46 tdf#79877 perf loading docx file, activate SAX threading It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, great thing, to get the old input-field dialog back. One small favour I would like to ask, though. ;-) Whenever you double-click you generally intend to change the value within the input-field. So it would be great if the existing content would be selected as default [as it was with the old input-field dialog]. At the moment you will have to double-click the content to start editing. It would be great if this could be implemented. Thanks!
(In reply to D.F. from comment #21) > One small favour I would like to ask, though. ;-) > > Whenever you double-click you generally intend to change the value within > the input-field. So it would be great if the existing content would be > selected as default [as it was with the old input-field dialog]. > At the moment you will have to double-click the content to start editing. > It would be great if this could be implemented. Sure, but please open a new issue.
Done that. Filed it under #119303. Thanks!