Issue 33737 - Allow for in-place editing of input field (turn off pop-up)
Summary: Allow for in-place editing of input field (turn off pop-up)
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1.2
Hardware: All All
: P3 Trivial with 57 votes (vote)
Target Milestone: 4.1.0
Assignee: Oliver-Rainer Wittmann
QA Contact:
URL:
Keywords: oooqa, rfe_eval_ok
: 35088 47799 52468 63429 79720 (view as issue list)
Depends on: 93321
Blocks: 101312 125108
  Show dependency tree
 
Reported: 2004-09-02 10:22 UTC by ftack
Modified: 2017-05-20 10:35 UTC (History)
26 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
patch file - first step (68.58 KB, patch)
2007-04-05 13:27 UTC, Oliver Specht
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description ftack 2004-09-02 10:22:58 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).
Comment 1 michael.ruess 2004-09-02 10:35:14 UTC
reassigned to BH.
Comment 2 lohmaier 2006-01-24 21:22:15 UTC
*** Issue 52468 has been marked as a duplicate of this issue. ***
Comment 3 lohmaier 2006-01-24 21:23:32 UTC
setting keywords, reassigning
Comment 4 lohmaier 2006-04-04 20:10:10 UTC
*** Issue 63429 has been marked as a duplicate of this issue. ***
Comment 5 Oliver Specht 2007-04-05 12:05:42 UTC
Taking over to hack around ab bit:-)
Adding mba on cc
Comment 6 Oliver Specht 2007-04-05 13:19:03 UTC
*** Issue 35088 has been marked as a duplicate of this issue. ***
Comment 7 Oliver Specht 2007-04-05 13:27:42 UTC
Created attachment 44228 [details]
patch file - first step
Comment 8 Oliver Specht 2007-04-05 14:17:22 UTC
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)






Comment 9 michael.ruess 2007-07-18 11:13:17 UTC
*** Issue 79720 has been marked as a duplicate of this issue. ***
Comment 10 noop 2007-08-11 00:46:21 UTC
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". 
Comment 11 flr 2007-09-28 13:09:32 UTC
Started implementation. Have inline input and .DOC import working. Currently
implementing .DOC export.

If anyone is interrested testing the current import let me know...
Comment 12 jr 2007-09-28 13:41:32 UTC
Great news! Thanks for starting the implementation. I would like to help testing
the import. Is it possible to get a cws for testing?
Comment 13 flr 2007-10-16 09:26:34 UTC
A snapshot of the current work can be found here:
http://florianreuter.blogspot.com/2007/10/update-on-field-work-early-preview.html.
Comment 14 noop 2007-10-18 20:25:54 UTC
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.
Comment 15 flr 2007-10-18 23:45:40 UTC
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
Comment 16 matthias.mueller-prove 2007-10-29 17:22:22 UTC
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
Comment 17 Mathias_Bauer 2007-12-04 12:46:16 UTC
target 3.0
Comment 18 kpalagin 2008-01-26 13:08:29 UTC
Florian,
are we on track for 3.0 with this enhancement?
Does it need to be finished before feature freeze or code freeze?
Comment 19 hiney 2008-02-05 00:02:45 UTC
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
Comment 20 flr 2008-02-05 18:00:20 UTC
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.
Comment 22 kpalagin 2008-02-05 18:50:16 UTC
Florian,
thanks a ton for your answer!

Is the patch ready?
Do you have an estimate of when it will be integrated into SRC?
Comment 23 flr 2008-02-05 19:30:06 UTC
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?
Comment 24 Mathias_Bauer 2008-02-05 20:22:18 UTC
@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. 
Comment 25 flr 2008-02-05 21:49:31 UTC
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.
Comment 26 hiney 2008-02-05 22:27:34 UTC
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
Comment 27 flr 2008-02-05 23:51:57 UTC
flr->hiney: Thx for the sample docs. Seems to work fine (at leasr the .DOC /
.RTF is not ready yet).
Comment 28 Mathias_Bauer 2008-02-06 08:07:25 UTC
Thanks Florian, I will commit the changes to a CWS and report back.
Comment 29 noop 2008-03-07 17:00:10 UTC
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).
Comment 30 sanderja 2008-05-13 13:57:18 UTC
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.
Comment 31 flr 2008-05-13 14:15:54 UTC
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
Comment 32 Mathias_Bauer 2008-05-16 14:45:35 UTC
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.
Comment 33 andreas.martens 2008-05-16 15:50:44 UTC
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...
Comment 34 sanderja 2008-05-20 14:50:02 UTC
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.
Comment 35 cno 2008-05-27 21:59:58 UTC
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
Comment 36 noop 2008-05-28 05:22:36 UTC
@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. 
Comment 37 noop 2008-05-28 21:09:05 UTC
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.

Comment 38 mux2005 2008-05-29 08:35:04 UTC
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.
Comment 39 flr 2008-05-29 11:36:02 UTC
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.

Comment 40 mux2005 2008-05-29 11:47:49 UTC
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.
Comment 41 flr 2008-05-29 11:54:51 UTC
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.
Comment 42 cno 2008-07-01 23:21:28 UTC
*** Issue 49604 has been marked as a duplicate of this issue. ***
Comment 43 Mathias_Bauer 2008-07-31 14:35:08 UTC
Will be integrated into 3.1
Comment 44 bjoern.michaelsen 2008-09-01 10:26:16 UTC
Assigning to self: integration of code introduced in cws swenhancedfields2
(issue 93321).
Comment 45 bjoern.michaelsen 2008-09-01 10:27:53 UTC
depends on 93321.
Comment 46 kpalagin 2008-11-07 21:38:58 UTC
b_michaelsen,
will this be integrated in 3.1?

Regards,
KP.
Comment 47 bjoern.michaelsen 2008-11-12 15:32:45 UTC
@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.
Comment 48 bjoern.michaelsen 2008-12-10 10:09:33 UTC
retargeting -> 3.X
Comment 49 kpalagin 2008-12-11 07:53:32 UTC
Not even 3.2?!
Comment 50 Mathias_Bauer 2008-12-11 08:33:43 UTC
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.
Comment 51 Joost Andrae 2009-07-07 13:30:17 UTC
CWS swenhancedfields2 has already been integrated into DEV300m31. What is left
to allow this issue to stay open ?
Comment 52 noop 2009-07-07 20:58:06 UTC
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.



Comment 53 Mathias_Bauer 2009-07-07 21:55:02 UTC
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.
Comment 54 Mathias_Bauer 2009-07-07 22:01:27 UTC
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.
Comment 55 andreschnabel 2009-07-08 06:49:58 UTC
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).

Comment 56 Mathias_Bauer 2009-07-08 07:47:19 UTC
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.
Comment 57 noop 2009-07-10 04:04:39 UTC
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? 
Comment 58 Mathias_Bauer 2009-07-10 07:12:09 UTC
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.
Comment 59 bjoern.michaelsen 2009-07-10 09:08:32 UTC
FYI, flr created cws field01 to resolve remaining issues and finish the
integration. However, I cant comment on the progress made there.
Comment 60 bjoern.michaelsen 2009-07-13 09:57:41 UTC
I just noticed flr isnt even cc'ed on this bug -> CC'ing flr.

P.S.: Also cc'ing od.
Comment 61 bjoern.michaelsen 2009-07-31 16:05:10 UTC
blocking 101312
Comment 62 Mathias_Bauer 2009-11-18 16:26:37 UTC
*** Issue 47799 has been marked as a duplicate of this issue. ***
Comment 63 martingprior 2011-01-21 16:33:43 UTC
Any progress / workarounds for this by now?
Still crappy input field editing with 3.3 m20!
Comment 64 hans_werner67 2011-02-03 12:08:26 UTC
pls. reassign or close issues.
Thx.
Comment 65 only1russ 2013-03-13 19:14:36 UTC
YES - Please continue to work on this patch!

Has there been any recent progress ?

Thanks!

-- Russ T.
Comment 66 Oliver-Rainer Wittmann 2013-09-24 14:33:40 UTC
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?
Comment 67 SVN Robot 2013-09-24 15:03:39 UTC
"orw" committed SVN revision 1525917 into trunk:
33737: - some minor refactoring in advance
Comment 68 jr 2013-09-25 15:16:19 UTC
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.
Comment 69 Oliver-Rainer Wittmann 2013-09-27 09:25:45 UTC
(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.
Comment 70 Oliver-Rainer Wittmann 2013-11-06 14:29:20 UTC
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.
Comment 71 SVN Robot 2013-11-18 11:32:29 UTC
"orw" committed SVN revision 1542986 into trunk:
33737: enable in-place editing of Input Fields
Comment 72 SVN Robot 2013-11-18 11:56:47 UTC
"orw" committed SVN revision 1543006 into trunk:
33737: remove accicently added svn property 'svn:executable' at new source files
Comment 73 Oliver-Rainer Wittmann 2013-11-18 11:58:00 UTC
solution for the in-place editing of Input Fields as documented in the wiki (see comment #70) integrated into trunk.
Comment 74 SVN Robot 2013-12-10 15:24:52 UTC
"orw" committed SVN revision 1549864 into trunk:
33737: correction: assure the selections does not start/end inside a table wh...
Comment 75 Oliver-Rainer Wittmann 2013-12-10 15:43:20 UTC
(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.
Comment 76 Atila 2014-06-14 20:09:44 UTC
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.
Comment 77 Oliver-Rainer Wittmann 2014-06-16 08:23:35 UTC
(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.
Comment 78 Atila 2014-06-17 13:04:55 UTC
(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.
Comment 79 Oliver-Rainer Wittmann 2014-06-19 06:14:50 UTC
(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.