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.

*** Bug 59254 has been marked as a duplicate of this bug. ***

I set the version to the first LO 3.6 - see comment 1

*** Bug 68539 has been marked as a duplicate of this bug. ***

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

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)

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.

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)

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

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

@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!

(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".

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

I confirm it happens on 4.2.6.3.

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!!

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")

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...

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?

This looks relevant:

warn:legacy.osl:8027:1:svx/source/form/formcontrolfactory.cxx:207: lcl_getDataSourceIndirectProperties: could not determine the form!

(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.

Created attachment 112455 [details]
reproduction example in Writer

(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.

(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.

Alas, fix of the root cause of fdo#73059 doesn't seem to help here, I'm stuck :-(

I meant, trying to apply the same kind of fix... I didn't expect the fix of fdo#73059 solved this one.

*** Bug 92994 has been marked as a duplicate of this bug. ***

*** Bug 98383 has been marked as a duplicate of this bug. ***

Moving columns of a table control works fine with OpenOffice4 but not with LibreOffice 5.3

Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=61d78aca81f08ac3a0f9eb65799d04d56fbad312..0bbf79005a697c6781047c01f05eb660836a18e1

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

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.

(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.

(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.

see also associated bug 114814

*** Bug 119382 has been marked as a duplicate of this bug. ***

 (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.

With LO 6.3.3.2 on OpenSUSE 15.1 64bit rpm Linux the fields could be copied:
Set the mouse on the column-header.
Click left button of the mouse.
Move the mouse - a "+" appears here.
Release the left button of the mouse.
The field has been "copied".

Note: Only the data-connection will be copied.
All formats of the original fields will be lost.

So nothing has been changed for this bug. Moving of fields in a tablecontrol is still impossible.

After some debugging it seems copy starts after workaround because
right click calls ensureRowSetConnection:
#0  dbtools::lcl_connectRowSet(com::sun::star::uno::Reference<com::sun::star::sdbc::XRowSet> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool, com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&)
    (_rxRowSet=uno::Reference to (frm::ODatabaseForm *) 0x7be7ef8, _rxContext=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x127a070, _bAttachAutoDisposer=false, _rxParent=empty uno::Reference) at connectivity/source/commontools/dbtools.cxx:368
#1  0x00007f705f95ef61 in dbtools::ensureRowSetConnection(com::sun::star::uno::Reference<com::sun::star::sdbc::XRowSet> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&)
    (_rxRowSet=uno::Reference to (frm::ODatabaseForm *) 0x7be7ef8, _rxContext=uno::Reference to (cppu::(anonymous namespace)::ComponentContext *) 0x127a070, _rxParent=empty uno::Reference)
    at connectivity/source/commontools/dbtools.cxx:483
#2  0x00007f704fa1e2b5 in dbaui::SbaGridControl::IsReadOnlyDB() const (this=0x858f290) at dbaccess/source/ui/browser/sbagrid.cxx:914
#3  0x00007f704fa2297e in dbaui::SbaGridHeader::PreExecuteColumnContextMenu(unsigned short, PopupMenu&) (this=0x32bd3a0, nColId=2, rMenu=...) at dbaccess/source/ui/browser/sbagrid.cxx:551
#4  0x00007f706800e914 in FmGridHeader::triggerColumnContextMenu(Point const&) (this=0x32bd3a0, _rPreferredPos=Point = {...}) at svx/source/fmcomp/fmgridcl.cxx:992

Indeed without this connection, you go in the if block there:
    244     if  (   sFieldName.isEmpty()
    245         ||  sCommand.isEmpty()
    246         ||  (   sDatasource.isEmpty()
    247             &&  sDatabaseLocation.isEmpty()
    248             &&  !xConnection.is()
    249             )
    250         )
    251     {
    252         OSL_FAIL( "FmGridHeader::ExecuteDrop: somebody started a nonsense drag operation!!" );
    253         return DND_ACTION_NONE;
    254     }

It can be fixed with this:
diff --git a/dbaccess/source/ui/browser/sbagrid.cxx b/dbaccess/source/ui/browser/sbagrid.cxx
index 41a30c9df178..cdbdf265cad2 100644
--- a/dbaccess/source/ui/browser/sbagrid.cxx
+++ b/dbaccess/source/ui/browser/sbagrid.cxx
@@ -1046,6 +1046,7 @@ void SbaGridControl::DoColumnDrag(sal_uInt16 nColumnPos)
 {
     Reference< XPropertySet >  xDataSource = getDataSource();
     OSL_ENSURE(xDataSource.is(), "SbaGridControl::DoColumnDrag : invalid data source !");
+    ::dbtools::ensureRowSetConnection( Reference< XRowSet >(getDataSource(),UNO_QUERY), getContext(), nullptr );
 
     Reference< XPropertySet > xAffectedCol;
     Reference< XPropertySet > xAffectedField;

So now, there's still the initial move pb.

(In reply to Xisco Faulí from comment #32)
> Regression introduced in range
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=61d78aca81f08ac3a0f9eb65799d04d56fbad312..
> 0bbf79005a697c6781047c01f05eb660836a18e1

Xisco: I tried to find what could be the culprit in this range but don't see (or missed it) which one could be a candidate. Are you sure we can rely on it?
Would it be possible to bibisect on 1 commit only instead of a range?
So we could at least revert the commit (hoping it's still possible since LO code must have changed) and test again.

Just for the record, I submitted a patch to review about copy part:
https://gerrit.libreoffice.org/c/core/+/106849

Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/44f1ed1928d4d32b1a1962f413df69e2ae851789

Related tdf#54021: Fields in tablecontrols of a form could not be copied

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I removed target 7.2.0 since it only concerns copy part.

(In reply to Lionel Elie Mamane from comment #22)
> Created attachment 112455 [details]
> reproduction example in Writer

On pc Debian x86-64 with master sources updated today, I still can reproduce this.
There's still:
warn:legacy.osl:33190:33190:svx/source/fmcomp/fmgridcl.cxx:252: FmGridHeader::ExecuteDrop: somebody started a nonsense drag operation!!

The commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=44f1ed1928d4d32b1a1962f413df69e2ae851789
"Related tdf#54021: Fields in tablecontrols of a form could not be copied
See https://bugs.documentfoundation.org/show_bug.cgi?id=54021#c42
for more details.
Of course there's still the main pb to fix, moving columns
"
isn't sufficient here.

Indeed, LO retrieves:
- no existing connection
- no datasource name
- no URL

I noticed you used registered database "Bibliography".

So I tried to retrieve it and use it as url but got 2 problems:
1) I used "Bibliography" directly in the code because I didn't know how to retrieve the name of used registered database from the odb file

2) I got url: file:///home/julien/lo/libreoffice/instdir/user/database/biblio.odb (which exists)
but it still couldn't create a connection from it.

Here's a quick dirty test patch:
diff --git a/connectivity/source/commontools/dbtools.cxx b/connectivity/source/commontools/dbtools.cxx
index d8ce3f42136e..c27de79809ef 100644
--- a/connectivity/source/commontools/dbtools.cxx
+++ b/connectivity/source/commontools/dbtools.cxx
@@ -20,6 +20,7 @@
 #include <connectivity/CommonTools.hxx>
 #include <TConnection.hxx>
 #include <ParameterCont.hxx>
+#include <comphelper/processfactory.hxx>
 
 #include <com/sun/star/awt/XWindow.hpp>
 #include <com/sun/star/beans/NamedValue.hpp>
@@ -46,6 +47,7 @@
 #include <com/sun/star/sdb/XSingleSelectQueryComposer.hpp>
 #include <com/sun/star/sdbc/ConnectionPool.hpp>
 #include <com/sun/star/sdbc/DataType.hpp>
+#include <com/sun/star/sdb/DatabaseContext.hpp>
 #include <com/sun/star/sdbc/XConnection.hpp>
 #include <com/sun/star/sdbc/XDataSource.hpp>
 #include <com/sun/star/sdbc/XParameters.hpp>
@@ -413,9 +415,20 @@ static SharedConnection lcl_connectRowSet(const Reference< XRowSet>& _rxRowSet,
 
             xPureConnection = getConnection_allowException( sDataSourceName, sUser, sPwd, _rxContext, _rxParent );
         }
-        else if (!sURL.isEmpty())
+        else
         {   // the row set has no data source, but a connection url set
             // -> try to connection with that url
+            if (sURL.isEmpty())
+            {
+                Reference< XDatabaseContext > xRegistrations(
+                    DatabaseContext::create(
+                    comphelper::getProcessComponentContext()));
+                OUString sName("Bibliography");
+                if (xRegistrations->hasRegisteredDatabase( sName ) )
+                {
+                    sURL = xRegistrations->getDatabaseLocation( sName );
+                }
+            }
             Reference< XConnectionPool > xDriverManager;
             try {
                 xDriverManager = ConnectionPool::create( _rxContext );


I'm a bit stuck here.

Caolán: trying to understand how to trigger move action with Robert's example (the pb with Lionel's file is a bit different since the first issue to deal with is how to retrieve the connection in case of a registered database - here Bibliography - which must be used)

To make some tests, I used this patch:
diff --git a/dbaccess/source/ui/browser/sbagrid.cxx b/dbaccess/source/ui/browser/sbagrid.cxx
index 65b30505fbfc..467bb77ca2e7 100644
--- a/dbaccess/source/ui/browser/sbagrid.cxx
+++ b/dbaccess/source/ui/browser/sbagrid.cxx
@@ -1075,7 +1075,7 @@ void SbaGridControl::DoColumnDrag(sal_uInt16 nColumnPos)
         return;
 
     rtl::Reference<OColumnTransferable> pDataTransfer = new OColumnTransferable(xDataSource, sField, xAffectedField, xActiveConnection, ColumnTransferFormatFlags::FIELD_DESCRIPTOR | ColumnTransferFormatFlags::COLUMN_DESCRIPTOR);
-    pDataTransfer->StartDrag(this, DND_ACTION_COPY | DND_ACTION_LINK);
+    pDataTransfer->StartDrag(this, DND_ACTION_MOVE | DND_ACTION_LINK);
 }

I think it might rather require here DND_ACTION_COPYMOVE (to have Move action by default and Copy if I type Ctrl Key when dragging field) but I wanted to be sure to test with DND_ACTION_MOVE.
I put some traces in vcl/unx/gtk3/gtk3gtkframe.cxx, I confirm ACTION_MOVE is well detected.

Then I noticed https://developer.gnome.org/gdk3/stable/gdk3-Drag-and-Drop.html
"
GDK_ACTION_MOVE
Move the data, i.e. first copy it, then delete it from the source using the DELETE target of the X selection protocol.
"

I searched about "DELETE target" and found https://developer.gnome.org/gtkmm-tutorial/stable/sec-dnd-signals.html.fr#dnd-signal-move 
"
drag_data_delete: Gives the source the opportunity to delete the original data if that's appropriate.
"

So I wonder if the pb isn't the missing drag_data_delete (at least for gtk3).
Trying to understand all this, I noticed this comment in vcl/unx/gtk3/gtk3gtkframe.cxx
// For LibreOffice internal D&D we provide the Transferable without Gtk
// intermediaries as a shortcut, see tdf#100097 for how dbaccess depends on this

it corresponds to:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=73f84ab139cb1d2564f9292fba08d69a0ab822c1
"
Resolves: tdf#100097 dbaccess self-dnd depends on getting its own transferable
on drop that it set on drag. It does some uno tunnel foo to drag the data it
needs back out of it in some grotesque fashion.

So we have to follow the same style of hackery as under MacOSX to detect
on drop that there is an active drag started by ourself and so use that
active drag's transferable as the source transferable for the drop, rather
that use the intermediate universal GtkDnDTransferable.
"

Now I suppose we must add this signal but I got no idea how to implement this.
Of course there will still be how to apply this on other envs like Mac, Win, Kf5,..

Using https://bugs.documentfoundation.org/attachment.cgi?id=112455 and digging into what is different between old working state and current state I strangely see that:

back in the working case we get a FmXGridControl from a sControlServiceName of "com.sun.star.form.control.GridControl" in ViewObjectContactOfUnoControl_Impl::createControlForDevice

now we get a SbaXGridControl from "com.sun.star.form.control.GridControl" instead. (SbaXGridControl inherits from FmXGridControl)

looks to me that SbaXGridControl has drag and drop support that FmXGridControl does not, and that this is the difference that has triggered all this

com.sun.star.form.control.GridControl appears in dbaccess/util/dbu.component and SbaXGridControl::getSupportedServiceNames

but 

svx/source/form/fmservs.cxx has ImplSmartRegisterUnoServices and the last entry of REGISTER_SERVICE(FmXGridControl, FM_SUN_CONTROL_GRIDCONTROL); 

expands to...

uno::Reference< lang::XMultiServiceFactory >  xServiceFactory = ::comphelper::getProcessServiceFactory();
uno::Reference< container::XSet >  xSet(xServiceFactory, uno::UNO_QUERY);
OUString sString = "com.sun.star.form.control.GridControl";
xSingleFactory = ::cppu::createSingleFactory(xServiceFactory,
                    OUString(), FmXGridControl_NewInstance_Impl,
                    uno::Sequence< OUString>(&sString, 1));
xSet->insert(uno::makeAny(xSingleFactory));

which sort of looks like it wants to replace the default target of "com.sun.star.form.control.GridControl" with a replacement

caolam->sberg: IYO what is ImplSmartRegisterUnoServices trying to do ?

Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/d8ede5d2f592084f76cc8888d42c3f1f5875e894

Related tdf#54021: Fields in tablecontrols of a form could not be copied

It will be available in 7.1.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

https://gerrit.libreoffice.org/c/core/+/107883 makes it work like the distant past and use FmXGridControl_NewInstance_Impl at which point the mouse dragging moves the columns around

(In reply to Caolán McNamara from comment #51)
> https://gerrit.libreoffice.org/c/core/+/107883 makes it work like the
> distant past and use FmXGridControl_NewInstance_Impl at which point the
> mouse dragging moves the columns around
On pc Debian x86-64 with master sources updated today + gtk3 + patch from gerrit, the move works but copy doesn't work (even when using Ctrl or shift + using or not the small patch about DND_ACTION_COPYMOVE instead of DND_ACTION_COPY from https://bugs.documentfoundation.org/show_bug.cgi?id=54021#c48).

(In reply to Julien Nabet from comment #52)
> On pc Debian x86-64 with master sources updated today + gtk3 + patch from
> gerrit, the move works but copy doesn't work (even when using Ctrl or shift
> + using or not the small patch about DND_ACTION_COPYMOVE instead of
> DND_ACTION_COPY from
> https://bugs.documentfoundation.org/show_bug.cgi?id=54021#c48).

Moving is the feature I am missing. I never use copying, because I don't need 2 fields with the same content. Don't know if anybody else will need this. It will only make sense when changing the fields afterwords and connect them to different database fields.

Good progress Julian and everyone.  Thank you.  I've been watching, and trying to learn as you do.  This is an important thing to have working.

Version: 7.1.5.2 (x64) / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5

I tried it again, but sorting of table column is not possible. Trying to move a table column -> copy of table column. This doesn't make any sense for me.

Tested with LO 7.6.1.1 on OpenSUSE 15.4 64bit rpm Linux.
Moving fields of a table control while editing a form doesn't work. Bug still exist.