Bug Hunting Session
Bug 54021 - EDITING: Fields in tablecontrols of a form could not be moved/sorted
Summary: EDITING: Fields in tablecontrols of a form could not be moved/sorted
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta1
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
: 59254 68539 92994 98383 119382 (view as bug list)
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2012-08-24 18:29 UTC by Robert Großkopf
Modified: 2018-11-23 08:58 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Headers of a tablecontrol could not be moved - screenshots of LO 3.3.4 and LO 3.6.1.1 rc (21.34 KB, application/vnd.oasis.opendocument.text)
2012-08-24 18:29 UTC, Robert Großkopf
Details
Open the form for editing - try to move the field "Street" to the left. (11.02 KB, application/vnd.sun.xml.base)
2013-10-29 12:14 UTC, Robert Großkopf
Details
reproduction example in Writer (11.27 KB, application/vnd.oasis.opendocument.text)
2015-01-19 11:14 UTC, Lionel Elie Mamane
Details
LO 6 DB to demo bug (10.96 KB, application/vnd.sun.xml.base)
2018-01-02 07:17 UTC, Howard Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2012-08-24 18:29:28 UTC
Created attachment 66079 [details]
Headers of a tablecontrol could not be moved - screenshots of LO 3.3.4 and LO 3.6.1.1 rc

Open a form for editing. Create a tablecontrol-field. You could find this control, when you open "More Controls".
You can choose fields, that should be shown in this tablecontrol. When you will change the position of this fields (tableheaders) you have to push the left button of the mouse and move the mouse to the new position. An arrow appears and the field would be moved.
This works in LO 3.3.*, LO 3.4.* and LO 3.5.*. 
When you try the same in LO 3.6.1.1 rc, the symbol for copying the field (tableheaders) appears. But the field isn't copied. There appears only a symbol and you cannot move the field. There is no possibility to move a field from one position to another.
Comment 1 Christian 2012-08-25 11:45:56 UTC
I'm able to reproduce this bug with LO Version 3.6.0.4 (Build ID: 932b512)

In my test case, the field is copied after drag and drop.
Comment 2 Robert Großkopf 2013-01-12 21:04:06 UTC
*** Bug 59254 has been marked as a duplicate of this bug. ***
Comment 3 Robert Großkopf 2013-02-10 11:27:42 UTC
I set the version to the first LO 3.6 - see comment 1
Comment 4 Robert Großkopf 2013-08-27 20:07:15 UTC
*** Bug 68539 has been marked as a duplicate of this bug. ***
Comment 5 Robert Großkopf 2013-08-28 06:10:59 UTC
Have tried to find the first version, where this bug appears.
I tested with LO 3.6.0.0 beta1. There it's impossible to move the fields. There are no earlier versions for me available.
In https://bugs.freedesktop.org/show_bug.cgi?id=68539 I have also tested with LO 3.5.7.2. In this version the fields could only moved from the right side to the left side. So there is also something buggy inside.
I set the version for this bug to 3.6.0.0 beta1
Comment 6 Joel Madero 2013-10-29 03:15:31 UTC
Please attach a document that has the form (not just a word document, an actual document that we can easily test). Marking as NEEDINFO - once you attach please mark as UNCONFIRMED (please don't mark as NEW as it hasn't been independently confirmed)
Comment 7 Robert Großkopf 2013-10-29 12:14:06 UTC
Created attachment 88288 [details]
Open the form for editing - try to move the field "Street" to the left.

Why shouldn't I set this Bug to "New"? It is confirmed by many people in LO-forum, also by comment1 in this bug description.
Comment 8 Joel Madero 2013-10-29 12:24:28 UTC
Because it's missing a lot of information that QA would add. Simply saying "I can confirm" isn't enough. Since it's a regression a bibisect will be useful, plus there is no information about operating systems, if it's been tested on 4.1 or newer, etc . . .

If you could provide your system info along with the latest version that you've tested on (please don't update the version field, just leave a comment)
Comment 9 Joel Madero 2013-10-29 13:26:58 UTC
Thank you for reporting this issue! I have been able to confirm the issue on:
Version 4.1.2.2 &
Version 4.2 master from a few days ago 

Platform: Ubuntu 13.10 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 

Marking as:

New (confirmed)
Normal - can prevent high quality work, unless I am missing a workaround for the problem, completely prevents sorting the way you want
High - Regression, bumped up from 

Keywords - regression

Whiteboard Status - bibisected

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 10 Joel Madero 2013-10-29 13:27:53 UTC
Lionel - one for you I suppose


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3dd564c99651edb7fc45bea4afec8e98f7a8aa19 is the first bad commit
commit 3dd564c99651edb7fc45bea4afec8e98f7a8aa19
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed May 2 19:14:52 2012 +0200

    source-hash-0bbf79005a697c6781047c01f05eb660836a18e1
    
    commit 0bbf79005a697c6781047c01f05eb660836a18e1
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Mon Apr 23 11:47:45 2012 +0200
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Mon Apr 23 11:47:45 2012 +0200
    
        Do not fail for legacy rdb that only contains root key

:100644 100644 b453a604fc3c5fb4f63f3aed412de93d20c55f20 30cc0b83db3fdcc1184dc05167bee66d47065710 M	ccache.log
:100644 100644 5b0c05d5b6e9bda9bd68f447b69ed7bed74e3f33 06d353cf5a0dd1d1225f43c0f21e1401f4316324 M	commitmsg
:100644 100644 c6128a76d64ef1fe9d7cfd8fbb4cddb737fcf551 e9791ae34f56f896af9eeb3ad1a21850bb54b086 M	dev-install.log
:100644 100644 c0a3d2e12aaac1a7028a9d2c80d22e60efd1998f 43a4d682bdd87ac9421ebe7a42ce229c9f1acba7 M	make.log
:040000 040000 39dc0b7004ecedf0b4458a6b1df2c44f75bb8725 ae3ab874138db9d0d407fc0f11d1738a17f398b8 M	opt
:100644 100644 3098f58f38447b6f729b16c23f3edcc4ae973b8a 27ab6b5b5adb9e65e24651db698082531c3d5593 M	patch.log


# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# skip: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect skip 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# skip: [1b33e76db9e293bea69b7f814ee90a52a10f7a57] source-hash-cac1f33e839469d884730350e46a21d92fb442f2
git bisect skip 1b33e76db9e293bea69b7f814ee90a52a10f7a57
# bad: [bc003d6498b1bb1188ed2387d87f6723d5a329c7] source-hash-c8218367a0f52206591a5048848fa5292405b6c3
git bisect bad bc003d6498b1bb1188ed2387d87f6723d5a329c7
# good: [644d874f93754099832af82fdd48034d9710692b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect good 644d874f93754099832af82fdd48034d9710692b
# bad: [5d495e9d278412d3719fe3d18b429d2b34831241] source-hash-4f5c523b97542bdbfe69fb7695bcb9699c66f89f
git bisect bad 5d495e9d278412d3719fe3d18b429d2b34831241
# bad: [b3d0d6cf5ddad3c3642ec069bcc2946f7f4b2853] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf
git bisect bad b3d0d6cf5ddad3c3642ec069bcc2946f7f4b2853
# good: [897cb6dda02ae841cd1831e132de2aba7821a601] source-hash-212c18430864f110e5a3549c0279b1a2ea4bb6bd
git bisect good 897cb6dda02ae841cd1831e132de2aba7821a601
# bad: [5cec9e21c2a7ccf772046a19234d065b40753526] source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9
git bisect bad 5cec9e21c2a7ccf772046a19234d065b40753526
# bad: [3dd564c99651edb7fc45bea4afec8e98f7a8aa19] source-hash-0bbf79005a697c6781047c01f05eb660836a18e1
git bisect bad 3dd564c99651edb7fc45bea4afec8e98f7a8aa19
# good: [dda5f411582f8cab90cb3f9abc456fdadb972afb] source-hash-5553dfe2060cb4a02a827c9774a60e4408d20c33
git bisect good dda5f411582f8cab90cb3f9abc456fdadb972afb
# good: [df022a841cf6429cb6e6ccc2036df43aa4f5e9a6] source-hash-61d78aca81f08ac3a0f9eb65799d04d56fbad312
git bisect good df022a841cf6429cb6e6ccc2036df43aa4f5e9a6
# first bad commit: [3dd564c99651edb7fc45bea4afec8e98f7a8aa19] source-hash-0bbf79005a697c6781047c01f05eb660836a18e1
Comment 11 Joel Madero 2013-10-29 13:31:18 UTC
@Robert - wanted to leave a message explaining a bit more why we don't like users marking their own bugs as new. Once a bug is marked as new QA essentially ignores the bug unless we are pinged for a particular reason to look further into it. In this case it was marked as NEW without the proper information - which QA would have requested prior to you marking it as NEW had it been in UNCONFIRMED status. The most pertinent thing missing was the attachment which made my job about 100x faster (even though it was a simple test case, spending QA's time or worse, devs time, coming up with these simple test cases is not ideal as we are often forced to guess and check and hope we are making a test document similar to what the reporter had in mind). For the bare minimum of what we hope for in a bug report:

Reporters system specs (OS, and architecture)
LibreOffice version

If a regression
Last known version that it worked (if it's known)

and

the simplest test case attached to the bug.


Having these things makes our job a lot easier, and when we have thousands of bugs to confirm and comment on, the little things help a lot


Thanks for the attachment and your patience!
Comment 12 Robert Großkopf 2013-10-29 15:34:52 UTC
(In reply to comment #11)
> @Robert - wanted to leave a message explaining a bit more why we don't like
> users marking their own bugs as new. 

This is a (new) problem for me, when I report bugs. The last bugs I reported switch directly to "New" when I have submitted them. I haven't set my own bugs to "New", when there aren't other people, who could confirm the bugs - but the bugzilla did it (Examples: Bug70674, Bug70827).

---------------------------

Operating-System of this bug (or others): What should I write, when I get this message in a Base-forum from Windows-user and I am using Linux? I can't set anything in the platform.

The description had also the right information when this bug appears (not the last where it works, see comment5).

I know you are doing a good job as QA, but please be more careful when writing something like "if it's been tested on 4.1 or newer" for a bug-report from 2012-08-24.

The first I have readed, when I reported bugs: "Write clearly, what you do." - so I added screenshots and text, which should declare. Now I could read: "Add an example database" - for a bug, which only needs an empty table and starting the form-wizard. 

And then I read, that this bug should get high importance - I don't know why: You could delete fields in the tablecontrol, you could add fields where you want - you only cant move the fields. This is a "cosmetical" Bug, not a functionality of the database broken with this bug. When you set this to "high", much of the other bugs I reported must be "highest".
Comment 13 Joel Madero 2013-10-29 17:13:44 UTC
Thanks for the compliment :)

As for priorities, pretty subjective but QA has some general policies that mix severity and priority, we tend to ask people not to change their own priorities as it just irritates developers and makes them distrust the system.

Here is the guide that we try to follow at least to some extent: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg


So if you report a bug and you think strongly it belongs somewhere in that flowchart, please put that in your comment and we'll take your opinion into consideration :) A lot of the times QA really is "guessing" at how popular a feature is or if there is or is not a workaround is also very important
Comment 14 senya 2014-10-15 12:57:34 UTC
I confirm it happens on 4.2.6.3.
Comment 15 Alex Thurgood 2015-01-03 17:39:39 UTC Comment hidden (no-value)
Comment 16 Julien Nabet 2015-01-17 21:01:39 UTC
On pc Debian x86-64 with master sources updated today, just opening the form for editing gave:
arn:legacy.osl:8268:1:unotools/source/config/moduleoptions.cxx:585: unknown factory
warn:legacy.osl:8268:1:unotools/source/config/moduleoptions.cxx:585: unknown factory
warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint
warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint
warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint
warn:legacy.tools:8268:1:sfx2/source/control/bindings.cxx:2182: No cache for OfficeDispatch!
warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint
warn:legacy.osl:8268:1:svtools/source/brwbox/brwbox2.cxx:1035: BrowseBox::ImplPaintData could not seek back to current row after paint

Then trying to move the field:
warn:legacy.osl:8268:5:svx/source/fmcomp/fmgridcl.cxx:265: FmGridHeader::ExecuteDrop: somebody started a nonsense drag operation!!
Comment 17 Julien Nabet 2015-01-17 22:11:23 UTC
just some debugging info about the test line which displays "FmGridHeader::ExecuteDrop: somebody started..."
sFieldName: Street
sCommand: Table
sDatasouce: 
sDatabaseLocation: 
xConnection.is(): 0

(BTW, I've just noticed a typo for "sDatasource")
Comment 18 Julien Nabet 2015-01-18 13:36:49 UTC
Unwinding a bit the lack of datasourcename:
OColumnTransferable::extractColumnDescriptor
http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#261

    285  // build the real descriptor
    286  return ODataAccessDescriptor(aDescriptorProps);

Then:
bool ODADescriptorImpl::buildFrom( const Sequence< PropertyValue >& _rValues )
http://opengrok.libreoffice.org/xref/core/svx/source/form/dataaccessdescriptor.cxx#100
when pValues->Name = "DataSourceName"
pValues->Value = <Any: (string) >

then:
void ODataAccessDescriptor::setDataSource(const OUString& _sDataSourceNameOrLocation)
http://opengrok.libreoffice.org/xref/core/svx/source/form/dataaccessdescriptor.cxx#390
"_sDataSourceNameOrLocation" is empty

then:
    164     void OColumnTransferable::implConstruct( const OUString& _rDatasource
    165                                             ,const OUString& _rConnectionResource
    166                                             ,const sal_Int32 _nCommandType
    167                                             ,const OUString& _rCommand
    168                                             , const OUString& _rFieldName)
http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#164
"_rDatasource" is empty

then:
     86     OColumnTransferable::OColumnTransferable(const Reference< XPropertySet >& _rxForm,
     87             const OUString& _rFieldName, const Reference< XPropertySet >& _rxColumn,
     88             const Reference< XConnection >& _rxConnection, sal_Int32 _nFormats)
     89         :m_nFormatFlags(_nFormats)
     90     {

must dig on...
Comment 19 Julien Nabet 2015-01-18 14:44:02 UTC
86 OColumnTransferable::OColumnTransferable(const Reference< XPropertySet >& _rxForm,
87 const OUString& _rFieldName, const Reference< XPropertySet >& _rxColumn,
88 const Reference< XConnection >& _rxConnection, sal_Int32 _nFormats)
89 :m_nFormatFlags(_nFormats)
http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/dbaexchange.cxx#86

102  _rxForm->getPropertyValue(FM_PROP_DATASOURCE)   >>= sDatasource;
103  _rxForm->getPropertyValue(FM_PROP_URL)          >>= sURL;
gives empty strings.

SbaGridControl::DoColumnDrag
http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/browser/sbagrid.cxx#1120
1152     OColumnTransferable* pDataTransfer = new OColumnTransferable(xDataSource, sField, ...

So xDataSource doesn't contain all the information.

Lionel: any idea if it's the good lead to follow?
Comment 20 Lionel Elie Mamane 2015-01-18 20:05:22 UTC
This looks relevant:

warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207: lcl_getDataSourceIndirectProperties: could not determine the form!
Comment 21 Julien Nabet 2015-01-18 21:16:22 UTC
(In reply to Lionel Elie Mamane from comment #20)
> This looks relevant:
> 
> warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207:
> lcl_getDataSourceIndirectProperties: could not determine the form!

How did you retrieve this log? (with master sources? during form edition?)
I don't find a way to have it in console.
Comment 22 Lionel Elie Mamane 2015-01-19 11:14:35 UTC
Created attachment 112455 [details]
reproduction example in Writer
Comment 23 Lionel Elie Mamane 2015-01-19 11:19:24 UTC
(In reply to Julien Nabet from comment #21)
> (In reply to Lionel Elie Mamane from comment #20)
> > This looks relevant:
> > 
> > warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207:
> > lcl_getDataSourceIndirectProperties: could not determine the form!
> 
> How did you retrieve this log? (with master sources? during form edition?)

With the attached "reproduction example in Writer". I fixed this warning now (in master), but it does not fix this bug. In Writer, it copies the column. Very imperfectly I must say... no properties are copied except the data source.

Which makes me think that we have two separate bugs:

1) The drag'n drop copies instead of moving.

2) In base, nothing happens (the copy fails).

And possibly a third one:

3) The copy is partial.

Your investigations are interesting for bug "2" in the above list.
Comment 24 Julien Nabet 2015-01-20 20:40:43 UTC
(In reply to Lionel Elie Mamane from comment #22)
> Created attachment 112455 [details]
> reproduction example in Writer
With master sources updated today, it's even not possible for me to try a drag n drop since when I select column and try to move it, I've got a symbol indicating it's not possible.
Comment 25 Julien Nabet 2015-01-26 22:11:16 UTC
Alas, fix of the root cause of fdo#73059 doesn't seem to help here, I'm stuck :-(
Comment 26 Julien Nabet 2015-01-26 22:12:10 UTC
I meant, trying to apply the same kind of fix... I didn't expect the fix of fdo#73059 solved this one.
Comment 27 Lionel Elie Mamane 2015-07-29 13:11:50 UTC
*** Bug 92994 has been marked as a duplicate of this bug. ***
Comment 28 Robinson Tryon (qubit) 2015-12-13 11:09:33 UTC Comment hidden (obsolete)
Comment 29 Stéphane Aulery 2016-03-12 22:56:06 UTC
*** Bug 98383 has been marked as a duplicate of this bug. ***
Comment 30 QA Administrators 2017-05-22 13:20:13 UTC Comment hidden (obsolete)
Comment 31 Andreas Säger 2017-05-22 15:17:51 UTC
Moving columns of a table control works fine with OpenOffice4 but not with LibreOffice 5.3
Comment 33 Howard Johnson 2018-01-02 06:47:03 UTC
WORKAROUND:  First right click a field, any field, which opens up the shortcut menu (i.e. Column width.. | Insert column | ...), then click outside the shortcut menu to cancel it.  

Now field copy works!

____________
Bug confirmed on LO 6.0, linux 9.3
Comment 34 Howard Johnson 2018-01-02 07:17:21 UTC
Created attachment 138796 [details]
LO 6 DB to demo bug

Steps to reproduce bug:


1 Download the attached 'Base table field copy bug.odb'

2 Open it with LO 6.

3 Edit form named 'Table1'.  The form will open in edit mode.

4 In the top bar of the table control position your mouse pointer over the word 'txt' and press the left mouse button down and hold it.  The cell will highlight.

5 Use your mouse to drag right.  Notice the '+' sign (for make a copy) is now added to the mouse pointer.

6 In the area to the right of 'txt2' release the left mouse button.


Expected result: selected field should be duplicated.

Buggy result: nothing happened.


Workaround: See my workaround in my previous comment here.  If you first open, then cancel the field shortcut menu this makes the bug go away.
Comment 35 Robert Großkopf 2018-01-02 07:42:20 UTC
(In reply to Howard Johnson from comment #33)
> WORKAROUND:  First right click a field, any field, which opens up the
> shortcut menu (i.e. Column width.. | Insert column | ...), then click
> outside the shortcut menu to cancel it.  
> 
> Now field copy works!
> 
This bug is described for moving/sorting fields, not for copying fields. If copying fields isn't working please write a new bug for this problem.
Comment 36 Howard Johnson 2018-01-02 20:40:35 UTC
(In reply to robert from comment #35)
> This bug is described for moving/sorting fields, not for copying fields. If
> copying fields isn't working please write a new bug for this problem.

Sad state of affairs.  Broken for at least 5 years.  In the mean time, with the workaround described above, one can do a move via a copy and then delete.

I'm working on the related bug reports:

Bug 1) this one: 54021 - You can't move fields, and when you try nothing happens.

Bug 2) When you perform the workaround the mouse drag does a field copy (not the expected field move).  Actually I find copy more useful than a move, but I think both features are needed: copy & move.  Anyway copy is half way to a move.  Add a delete and we have a move, well almost...

Bug 3) As it turns out the copy doesn't work so well either.  It is only a copy of the original field, before edits were made.  So the 2nd workaround is to hand edit the new copy to change to, and move properties from the old field, prior to deleting it.


So notwithstanding these 3 bugs, with 2 workarounds and some elbow grease we can move and reorder fields.
Comment 37 Howard Johnson 2018-01-02 21:44:56 UTC
see also associated bug 114814
Comment 38 Drew Jensen 2018-08-20 19:18:36 UTC
*** Bug 119382 has been marked as a duplicate of this bug. ***
Comment 39 Drew Jensen 2018-08-21 11:43:16 UTC

 (In reply to Howard Johnson from comment #36)
> (In reply to robert from comment #35)
> > This bug is described for moving/sorting fields, not for copying fields. If
> > copying fields isn't working please write a new bug for this problem.
> 
> Sad state of affairs.  Broken for at least 5 years.  In the mean time, with
> the workaround described above, one can do a move via a copy and then delete.
> 
> I'm working on the related bug reports:
> 
> Bug 1) this one: 54021 - You can't move fields, and when you try nothing
> happens.
> 
> Bug 2) When you perform the workaround the mouse drag does a field copy (not
> the expected field move).  Actually I find copy more useful than a move, but
> I think both features are needed: copy & move.  Anyway copy is half way to a
> move.  Add a delete and we have a move, well almost...
> 
> Bug 3) As it turns out the copy doesn't work so well either.  It is only a
> copy of the original field, before edits were made.  So the 2nd workaround
> is to hand edit the new copy to change to, and move properties from the old
> field, prior to deleting it.
> 
> 
> So notwithstanding these 3 bugs, with 2 workarounds and some elbow grease we
> can move and reorder fields.


4 Bugs not 3 actually.

There is no workaround for rearranging tablecontrol columns in a Form that is opened in dataentry mode. Another feature lost shortly after the fork from OOo.